> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Oracle Database

> Connect self-managed Oracle Database, Amazon RDS for Oracle, or OCI Autonomous Database so Oleria can discover users, roles, privileges, risks, and audit activity.

Connect Oracle Database to Oleria to see every database user, role, and privilege, and the paths through which one user can act as another. Oleria also flags risky configurations, such as holders of the `DBA` role or `SYSDBA`, accounts with Oracle default passwords, and sensitive packages that `PUBLIC` can execute.

<Note>This integration supports self-managed Oracle Database (VM, on-premises, Exadata, OCI Base Database Service, and Oracle Database\@Azure, @Google Cloud, and @AWS), Amazon RDS for Oracle, and OCI Autonomous Database. Oracle Database 19c or later is required. Pick the setup path that matches your deployment below.</Note>

## What Oleria discovers

| Area | Detail |
| :- | :- |
| **Accounts** | Every database user: local and common users, password-authenticated users, OS-authenticated (`IDENTIFIED EXTERNALLY`) users, directory-mapped (`IDENTIFIED GLOBALLY`) users, schema-only (`NO AUTHENTICATION`) accounts, and proxy users. Oracle-maintained and cloud-maintained accounts appear as system accounts. Users who hold `SYSDBA`, the `DBA` role, or a privilege-escalation system privilege are flagged as administrators. Oleria also shows each account's status, profile, authentication type, creation date, last sign-in, and password change and expiry dates. |
| **Roles and groups** | Every role in each container, including `PUBLIC` and Oracle-maintained roles, with role-to-role nesting. Directory groups and app roles behind shared global schemas and global roles appear as groups. Their members come from your directory integration, not from Oracle. |
| **Resources** | The database, its containers (root and pluggable databases), schemas, objects, directories, and database links. Columns appear when a privilege is granted on them. Objects in Oracle-maintained schemas (for example `SYS`, `SYSTEM`, and `XDB`) appear only when they're granted to one of your users or roles. |
| **Access grants** | System privileges, schema privileges (Oracle Database 23ai), object, column, and directory grants, database links, schema ownership, and administrative privileges such as `SYSDBA`, `SYSOPER`, and `SYSBACKUP`. Grants `WITH ADMIN OPTION` and `WITH GRANT OPTION` are marked. |
| **Impersonation** | Proxy users, `BECOME USER` and `ALTER USER`, definer's-rights code, and directory groups that sign in through a shared global schema. |
| **Risk signals** | See [Risk signals](#risk-signals) below. |
| **Activity** | Unified audit trail events: sign-in success and failure, proxy sign-ins, sign-outs, user and role changes, account locks and unlocks, password changes, role and privilege grants and revokes, and system, audit policy, and profile changes. Statements that fail for lack of privilege appear as denied access. Requires the audit setup below. |

### Risk signals

Oleria reports these risks for Oracle Database:

* **Oracle DBA role**
* **Administrative privilege in the password file** - `SYSDBA`, `SYSOPER`, `SYSASM`, `SYSBACKUP`, `SYSDG`, `SYSKM`, or `SYSRAC`.
* **Account with an Oracle default password**
* **Privilege-escalation system privilege** - for example `GRANT ANY ROLE`, `ALTER USER`, `BECOME USER`, `EXECUTE ANY PROCEDURE`, or `ALTER SYSTEM`.
* **ANY data privilege** - for example `SELECT ANY TABLE`, `UPDATE ANY TABLE`, `EXEMPT ACCESS POLICY`, or `SELECT ANY DICTIONARY`.
* **Privilege held WITH ADMIN / GRANT OPTION**
* **Explicit grant to PUBLIC**
* **PUBLIC can execute a sensitive Oracle package (CIS)** - for example `UTL_FILE`, `UTL_HTTP`, `DBMS_SCHEDULER`, or `DBMS_SQL`.
* **Public database link with stored credentials**
* **Password never expires**
* **No account lockout**
* **No password complexity check**
* **Password expired**
* **Insecure initialization parameter** - `REMOTE_OS_AUTHENT=TRUE`, `O7_DICTIONARY_ACCESSIBILITY=TRUE`, `SEC_CASE_SENSITIVE_LOGON=FALSE`, or `AUDIT_SYS_OPERATIONS=FALSE` (`AUDIT_SYS_OPERATIONS` is checked on self-managed databases only).

<Note>The connector user's own profile (below) sets an unlimited password lifetime and no lockout, so Oleria reports **Password never expires**, **No account lockout**, and possibly **No password complexity check** on that user. Oleria doesn't report the privileges you grant the connector user for remediation actions as risks.</Note>

## Prerequisites

* A dedicated database user for Oleria, with the read privileges listed for your deployment below. You can't use `SYS`, because it always signs in as `SYSDBA`.
* Network access from Oleria to your database listener on the configured port. See [Network and encryption](#network-and-encryption).
* Optional: the `AUDIT_VIEWER` role and audit policies, if you want Oleria to show activity. See [Enable audit policies for activity](#enable-audit-policies-for-activity-optional).
* Optional: additional privileges, if you also want to run remediation actions. See [Remediation actions](#remediation-actions).

<Note>Before it saves the integration, Oleria checks that the connector user can read every required data dictionary view (users, roles, privileges, objects, proxies, profiles, procedures, database links, and directories). If it can't read one, Oleria refuses the connection with an error that names the missing grant. Optional views aren't checked; see [Known limitations](#known-limitations).</Note>

### Choose what one integration covers

The **Service Name** you connect to decides the scope:

* **A pluggable database (PDB) or non-CDB service** - Oleria covers that database. This is the only option for Amazon RDS for Oracle and OCI Autonomous Database.
* **The root service of a self-managed container database (`CDB$ROOT`)** - Oleria covers the root and every open PDB with one integration. This requires a common user (`C##` prefix) with `CONTAINER_DATA = ALL`. Without any `CONTAINER_DATA` setting, Oracle silently shows only the root, so Oleria refuses the connection.

## Set up the integration

<Tabs>
  <Tab title="Self-managed">
    <Steps>
      <Step title="Create a connector user in a PDB or non-CDB">
        Connect to the pluggable database (or the non-CDB) as an administrator and run:

        ```sql theme={null}
        CREATE PROFILE oleria_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED;
        CREATE USER oleria IDENTIFIED BY "<strong password>" PROFILE oleria_profile;
        GRANT CREATE SESSION, SELECT ANY DICTIONARY TO oleria;
        ```

        * `CREATE SESSION` lets the user sign in.
        * `SELECT ANY DICTIONARY` lets Oleria read users, roles, and grants. It doesn't expose password hashes.
        * The dedicated profile keeps the connector working. Under the `DEFAULT` profile, the password expires after 180 days and 10 failed sign-ins lock the user. If your policy requires a finite `FAILED_LOGIN_ATTEMPTS`, keep `PASSWORD_LOCK_TIME` short, for example `1/24` (one hour), and rotate the password yourself.

        To cover every PDB with one integration instead, skip this step and use the next one.
      </Step>

      <Step title="Create a common connector user in the root (optional)">
        Connect to `CDB$ROOT` as an administrator and run:

        ```sql theme={null}
        CREATE PROFILE c##oleria_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED CONTAINER = ALL;
        CREATE USER c##oleria IDENTIFIED BY "<strong password>" PROFILE c##oleria_profile CONTAINER = ALL;
        GRANT CREATE SESSION, SELECT ANY DICTIONARY TO c##oleria CONTAINER = ALL;
        ALTER USER c##oleria SET CONTAINER_DATA = ALL CONTAINER = CURRENT;
        ```

        Set `CONTAINER_DATA = ALL`. If the user has no `CONTAINER_DATA` setting, Oleria refuses the connection. If it lists specific containers, Oleria covers only those.
      </Step>

      <Step title="Grant access to the audit trail (optional)">
        To show activity, grant the audit viewer role:

        ```sql theme={null}
        GRANT AUDIT_VIEWER TO oleria;
        ```

        For a common user in the root, use `GRANT AUDIT_VIEWER TO c##oleria CONTAINER = ALL;`. Then enable the audit policies in [Enable audit policies for activity](#enable-audit-policies-for-activity-optional).
      </Step>

      <Step title="Choose the encryption">
        Decide how Oleria encrypts the connection. See [Network and encryption](#network-and-encryption). If your listener has a TLS (TCPS) endpoint with a certificate from a publicly trusted certificate authority, use **Verified TLS**.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Amazon RDS for Oracle">
    <Steps>
      <Step title="Create a connector user">
        Connect to the database as the RDS master user. On a container database (CDB) instance, connect to the tenant database, not the root. Run:

        ```sql theme={null}
        CREATE PROFILE oleria_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED;
        CREATE USER oleria IDENTIFIED BY "<strong password>" PROFILE oleria_profile;
        GRANT CREATE SESSION, SELECT ANY DICTIONARY TO oleria;
        ```
      </Step>

      <Step title="Grant access to the audit trail (optional)">
        The RDS master user can't grant `AUDIT_VIEWER`. Grant read access to the audit trail instead:

        ```sql theme={null}
        GRANT SELECT ON AUDSYS.UNIFIED_AUDIT_TRAIL TO oleria;
        ```

        Then enable the audit policies in [Enable audit policies for activity](#enable-audit-policies-for-activity-optional).
      </Step>

      <Step title="Find your instance endpoint">
        In the AWS console, open your RDS instance and copy the endpoint. You enter it as **Host** when you connect. Oleria doesn't look up the endpoint and needs no access to your AWS account.
      </Step>

      <Step title="Choose the encryption">
        * **Native network encryption over TCP** works with the default option group on the default port `1521`.
        * **Verified TLS** requires the `SSL` option in the instance's option group. The TLS port is commonly `2484`. Oleria verifies the certificate against the Amazon RDS certificate authority.

        **TLS without certificate verification** isn't available for RDS. See [Network and encryption](#network-and-encryption).
      </Step>
    </Steps>
  </Tab>

  <Tab title="OCI Autonomous Database">
    <Steps>
      <Step title="Create a connector user">
        Connect to the database as `ADMIN` and run:

        ```sql theme={null}
        CREATE PROFILE oleria_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED;
        CREATE USER oleria IDENTIFIED BY "<strong password>" PROFILE oleria_profile;
        GRANT CREATE SESSION, SELECT_CATALOG_ROLE TO oleria;
        ```

        <Note>Use `SELECT_CATALOG_ROLE`, not `SELECT ANY DICTIONARY`. On Autonomous Database, `SELECT ANY DICTIONARY` doesn't reach the dictionary views Oleria reads.</Note>
      </Step>

      <Step title="Grant access to the audit trail (optional)">
        To show activity, grant the audit viewer role:

        ```sql theme={null}
        GRANT AUDIT_VIEWER TO oleria;
        ```

        Then enable the audit policies in [Enable audit policies for activity](#enable-audit-policies-for-activity-optional).
      </Step>

      <Step title="Note the connection details">
        In the OCI Console, open the database and select **Database connection**. From a connection string, note the host, the port, and the service name.
      </Step>

      <Step title="Prepare TLS">
        Autonomous Database accepts only TLS connections, and Oleria always verifies the server certificate. Choose one:

        * **Mutual TLS (wallet).** Download the database wallet from **Database connection**, extract `cwallet.sso` from the ZIP file, and base64-encode it on one line:

          ```bash theme={null}
          # Linux
          base64 -w0 cwallet.sso
          # macOS
          base64 -i cwallet.sso
          ```

          You paste the output into the **Wallet (cwallet.sso, base64, optional)** field. Mutual TLS uses port `1522`.
        * **One-way TLS (no wallet).** On the database details page, edit **Mutual TLS (mTLS) authentication** and clear **Require mutual TLS (mTLS) authentication**. Autonomous Database requires an access control list or a private endpoint for this. Leave the wallet field empty. One-way TLS works on port `1521` or `1522`.

        If you restrict access with an access control list, contact [support@oleria.com](mailto:support@oleria.com) for the addresses to allow.
      </Step>
    </Steps>
  </Tab>
</Tabs>

### Network and encryption

Oleria connects directly to your database listener. Your network must allow connections from Oleria to the listener's host and port.

* **Host** must be a host name or IP address. Oleria refuses loopback, link-local, and cloud metadata addresses.
* If the listener redirects the connection, for example a RAC SCAN listener, Oleria follows up to four redirects. With TLS, Oleria refuses a redirect to a non-TLS endpoint.

Choose one of these **Encryption** options:

| Option | What it does | Available for |
| :- | :- | :- |
| **Native network encryption over TCP** | Connects over TCP and requires Oracle native network encryption and integrity. This is the default for self-managed and RDS. | Self-managed, Amazon RDS for Oracle |
| **TLS without certificate verification** | Encrypts with TLS but doesn't verify the server certificate. Use it only for a self-signed listener certificate. | Self-managed only |
| **Verified TLS** | Encrypts with TLS and verifies the server certificate. On self-managed databases, the certificate must chain to a publicly trusted certificate authority. On RDS, Oleria uses the Amazon RDS certificate authority. On Autonomous Database, it's the only option. | All deployments |

<Warning>Native network encryption protects against eavesdropping, but it doesn't authenticate the server. An attacker who can intercept the connection could capture data that lets them crack the connector user's password offline. Use **Native network encryption over TCP** only on a trusted network, such as a private link, VPN, or peered VPC. Use **Verified TLS** wherever your listener has a TLS endpoint.</Warning>

With **Native network encryption over TCP**, Oleria refuses a server that turns native encryption off, for example with `SQLNET.ENCRYPTION_SERVER = REJECTED`. After sign-in, Oleria also requires AES encryption and SHA-2 integrity. If the connection is refused for weak algorithms, set `SQLNET.ENCRYPTION_TYPES_SERVER` to AES algorithms and `SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER` to SHA-2 algorithms in the server's `sqlnet.ora`.

To connect with **Verified TLS** to a host name that the certificate doesn't carry, such as an IP address, alias, or load balancer name, enter the certificate's full subject in **Server Certificate DN (optional)**. Oleria then matches the subject instead of the host name, and still verifies the certificate chain.

### Enable audit policies for activity (optional)

Complete this section only if you want Oleria to show activity. Oleria reads the unified audit trail, which records only what an enabled audit policy audits. A default database records failed sign-ins and only some grants and revokes. It doesn't record successful sign-ins.

<Tabs>
  <Tab title="PDB, non-CDB, RDS, or Autonomous">
    In the database the integration connects to, run:

    ```sql theme={null}
    AUDIT POLICY ORA_ACCOUNT_MGMT;
    CREATE AUDIT POLICY oleria_logons ACTIONS LOGON, LOGOFF;
    AUDIT POLICY oleria_logons EXCEPT oleria;
    ```

    * `ORA_ACCOUNT_MGMT` records user creation, changes, and deletion, and role and privilege grants and revokes.
    * `oleria_logons` records successful and failed sign-ins, and sign-outs, of every user except the connector user.
  </Tab>

  <Tab title="CDB root">
    A policy enabled in `CDB$ROOT` covers only the root unless it's a common policy. In `CDB$ROOT`, run:

    ```sql theme={null}
    CREATE AUDIT POLICY c##oleria_account_mgmt ACTIONS CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, GRANT, REVOKE CONTAINER = ALL;
    AUDIT POLICY c##oleria_account_mgmt;
    CREATE AUDIT POLICY c##oleria_logons ACTIONS LOGON, LOGOFF CONTAINER = ALL;
    AUDIT POLICY c##oleria_logons EXCEPT c##oleria;
    ```
  </Tab>
</Tabs>

Keep the default `ORA_SECURECONFIG` policy enabled. Enable each policy for all users, as shown. A policy enabled only `BY` certain users, with a `WHEN` condition, or `EXCEPT` users other than the connector user records only part of the activity.

<Note>If the connector user can't read the audit trail, the sync continues without activity. It doesn't fail.</Note>

## Connect Oracle Database to Oleria

<Steps>
  <Step title="Open the integration">
    Sign in to your Oleria workspace and navigate to **Integrations** -> **Oracle Database** -> **Connect**.
  </Step>

  <Step title="Complete the connection form">
    Select your **Deployment** first. The form updates to show only the fields that deployment needs.

    <Tabs>
      <Tab title="Self-managed">
        | Field | Notes |
        | :- | :- |
        | **Deployment** | Select **Self-managed**. |
        | **Host** | Required. The host name or IP address of the database listener, without a port or path. An IPv6 address may be in brackets. |
        | **Port** | Defaults to `1521`. |
        | **Service Name** | Required. A PDB, non-CDB, or `CDB$ROOT` service. Letters, digits, and `_ . - $ #` only. |
        | **Username** | Required. The user you created above, for example `oleria` or `c##oleria`. Can't be `SYS` or contain a colon. |
        | **Password** | Required. |
        | **Encryption** | **Native network encryption over TCP** (default), **TLS without certificate verification**, or **Verified TLS**. |
        | **Server Certificate DN (optional)** | Shown with **Verified TLS**. The full subject the server certificate must carry, for example `CN=db.example.com,O=Example`. Replaces the host name check. |
      </Tab>

      <Tab title="Amazon RDS for Oracle">
        | Field | Notes |
        | :- | :- |
        | **Deployment** | Select **Amazon RDS for Oracle**. |
        | **Host** | Required. The instance endpoint. |
        | **AWS Region (optional)** | An AWS region name, for example `us-east-1`. Used only to link to the instance in the AWS console. |
        | **RDS Instance Identifier (optional)** | Used only to link to the instance in the AWS console. Oleria always connects to the endpoint entered as **Host**. |
        | **Port** | Defaults to `1521`. With **Verified TLS**, enter the TLS port, commonly `2484`. |
        | **Service Name** | Required. The service name of the database, or of the tenant database on a CDB instance. |
        | **Username** | Required. The user you created above. |
        | **Password** | Required. |
        | **Encryption** | **Native network encryption over TCP** (default) or **Verified TLS**. **TLS without certificate verification** is listed but refused for RDS. |
        | **Server Certificate DN (optional)** | Shown with **Verified TLS**. Use it only if you connect through a name the certificate doesn't carry. |
      </Tab>

      <Tab title="OCI Autonomous Database">
        | Field | Notes |
        | :- | :- |
        | **Deployment** | Select **OCI Autonomous Database**. |
        | **Host** | Required. The host from the database's connection string. |
        | **Port** | Defaults to `1522`, the only port for mutual TLS. |
        | **Service Name** | Required. The service name from the database's connection string. |
        | **Username** | Required. The user you created above. |
        | **Password** | Required. |
        | **Server Certificate DN (optional)** | The full subject the server certificate must carry. Leave it empty unless you connect through a name the certificate doesn't carry. |
        | **Wallet (cwallet.sso, base64, optional)** | Required for mutual TLS. The base64-encoded `cwallet.sso` on one line. Leave it empty for one-way TLS. |

        Autonomous Database has no **Encryption** field. Oleria always uses **Verified TLS**.
      </Tab>
    </Tabs>
  </Step>

  <Step title="Complete the connection">
    Select **Authenticate**. Oleria signs in, detects the deployment and scope, and checks that the connector user can read every required view. Oleria then saves the integration and begins the first sync.
  </Step>
</Steps>

<Note>After you save the integration, you can change only the **Password** and the **Wallet (cwallet.sso, base64, optional)**. Leave either empty to keep the stored value. To change any other field, connect a new integration.</Note>

## Verify the integration

Confirm Oracle Database appears on the **Connected** tab of your Oleria **Integrations** page. After the first sync completes, you can review the discovered accounts, roles, resources, access grants, risks, and activity in your Oleria workspace.

If the connection is refused with an error that names a missing grant, grant it to the connector user and try again.

<Note>After a failed sign-in, Oleria waits up to 10 minutes before it tries the same password again, so repeated retries can't lock the connector user. Updating the password in Oleria, or testing the connection again, retries immediately.</Note>

## Remediation actions

Oleria validates the connector user's privileges before it runs each action, and reads the current state first. If nothing needs to change, Oleria records the action as a no-op and never reverts it. **Lock Oracle User Account** also requires approval in Oleria.

| Action | What it does | Privileges the connector user needs |
| :- | :- | :- |
| **Grant Oracle Role to User** | Grants a role to a user (`GRANT role TO user`). Reversible: the revert revokes it. | `GRANT ANY ROLE`, or the role granted `WITH ADMIN OPTION` |
| **Revoke Oracle Role from User** | Revokes a role from a user (`REVOKE role FROM user`). Reversible: the revert grants it back with its original `ADMIN OPTION`, `DELEGATE OPTION`, and default role setting. | `GRANT ANY ROLE`, or the role granted `WITH ADMIN OPTION`, plus `ALTER USER` so the revert can restore the default role setting |
| **Lock Oracle User Account** | Locks the user (`ALTER USER … ACCOUNT LOCK`), then ends the user's open sessions so access stops immediately. Reversible: the revert unlocks the user. | `ALTER USER`. To end sessions, `ALTER SYSTEM`, or on Amazon RDS, `EXECUTE` on `rdsadmin.rdsadmin_util`. |

Grant the privileges for the actions you want to use:

<Tabs>
  <Tab title="PDB, non-CDB, or Autonomous">
    ```sql theme={null}
    GRANT GRANT ANY ROLE, ALTER USER TO oleria;
    GRANT ALTER SYSTEM TO oleria;
    ```
  </Tab>

  <Tab title="Amazon RDS for Oracle">
    The RDS master user can't grant `ALTER SYSTEM`. Oleria ends sessions through the RDS administration package instead:

    ```sql theme={null}
    GRANT GRANT ANY ROLE, ALTER USER TO oleria;
    GRANT EXECUTE ON rdsadmin.rdsadmin_util TO oleria;
    ```
  </Tab>

  <Tab title="CDB root">
    A grant made in the root reaches the PDBs only with `CONTAINER = ALL`. `SET CONTAINER` lets Oleria change local users in their own PDB.

    ```sql theme={null}
    GRANT GRANT ANY ROLE, ALTER USER, ALTER SYSTEM, SET CONTAINER TO c##oleria CONTAINER = ALL;
    ```
  </Tab>
</Tabs>

<Note>Without `ALTER SYSTEM` (or, on RDS, `EXECUTE` on `rdsadmin.rdsadmin_util`), the lock still succeeds, but the action output says that open sessions weren't ended. Those sessions keep access until they disconnect.</Note>

Oleria refuses an action when:

* the target is the connector user itself
* the target is an Oracle-maintained user, a cloud-maintained user on Autonomous Database, or `RDSADMIN` or `OPS$RDSDB` on Amazon RDS
* for a revoke, the role was granted commonly from `CDB$ROOT` (`CONTAINER = ALL`) and the integration connects to a PDB. Revoke it in `CDB$ROOT` with `CONTAINER = ALL` instead.
* for a lock or unlock, the target is a common user and the integration connects to a PDB. Common users can be locked and unlocked only through a `CDB$ROOT` integration.
* the database is open read-only, such as a Data Guard standby. Connect the integration to the primary database.
* Database Vault blocks the statement. Authorize the connector user, for example with the `DV_ACCTMGR` role or a realm or command rule authorization.

<Note>If a user was temporarily locked out by failed sign-ins (`LOCKED(TIMED)`) before a lock action, the revert leaves the user permanently locked, because Oracle can't re-create a timed lockout. The revert output says so.</Note>

## Known limitations

* **No account creation or deletion:** Oleria grants and revokes roles, and locks and unlocks users. It can't create, drop, or change the password of a database user.
* **Unified auditing only:** Oleria reads the unified audit trail. Traditional auditing (`AUDIT_TRAIL=DB`, `DBA_AUDIT_TRAIL`) and fine-grained auditing aren't read. If your database writes only traditional audit records, Oleria shows no activity.
* **Statement text is redacted:** Oleria removes literals, numbers, email addresses, and comments from audited statements, and never reads bind values. Oracle already masks passwords in audited statements.
* **Synthetic email:** Most Oracle users have no email address. Oleria synthesizes one from the user name, container or database name, and host, which may not match a real address. Directory-mapped users with a user principal name use that address instead.
* **Group membership:** Members of directory groups behind global users and roles come from your Microsoft Entra ID, Active Directory, or other directory integration, not from Oracle.
* **Restrictive security features aren't evaluated:** Database Vault, Oracle Label Security, Real Application Security, Data Redaction, and Virtual Private Database policies are recorded as labels, not evaluated. Oleria may show more access than these features allow.
* **Access outside the database isn't visible:** Operating system users who sign in as `SYSDBA` through OS groups (`/ as sysdba`) aren't in the data dictionary. AWS and OCI identities that can reset the master or `ADMIN` password are visible only through your cloud integration.
* **Not covered:** Scheduler jobs and credentials, and roles granted to PL/SQL code (code-based access control).
* **Partial reads don't fail the sync:** If the connector user can't read an optional view, such as the password file users, default passwords, Database Vault, Data Redaction, or VPD views, Oleria syncs the rest and records what it couldn't collect.
* **Containers that aren't open:** In a `CDB$ROOT` integration, PDBs that aren't open are listed as skipped and aren't scanned. Seed PDBs aren't shown.
* **Very large databases:** One integration handles about 8 to 10 million dictionary objects. For a larger container database, connect each PDB as its own integration.
* **Connector authentication:** The connector user signs in with a password. Kerberos, RADIUS, token-based authentication, and Secure External Password Store wallets aren't supported for the connector user.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.