← Data Console

Browse Oracle without granting everyone a schema account

Oracle access tends to be all-or-nothing: an account with a role attached, and a client to use it from. For the people who need to answer a question rather than run the database, the console is a narrower door — specific tables, masked columns, and a record of who read what.

Create a read-only Oracle user

Run against a live server, then re-connected as that user to confirm SELECT worked and INSERT and DROP were refused.

-- Oracle Free 23, verified.
-- In Oracle a user IS a schema, and a new one cannot even connect
-- until it is granted a session.
CREATE USER dbshift_ro IDENTIFIED BY "AStrongPassword1";
GRANT CREATE SESSION TO dbshift_ro;

-- Then grant reads on what it should see, object by object.
GRANT SELECT ON app_schema.customers TO dbshift_ro;
GRANT SELECT ON app_schema.orders    TO dbshift_ro;

What browsing Oracle looks like

  • NUMBER columns keep their declared precision and scale, so a monetary column is not rendered as a float.
  • CLOB and BLOB columns are recognised rather than truncated into an unreadable cell.
  • TIMESTAMP WITH TIME ZONE keeps its offset.
  • Foreign keys are followed in one click, including composite keys.

What catches people out on Oracle

An Oracle DATE carries a time

Unlike most engines, DATE includes hours, minutes and seconds. A tool that renders it as a day silently drops the time, which is a common source of 'the export does not match the screen'.

Empty string is NULL

Oracle stores '' as NULL, so a NOT NULL column can never hold an empty string and a filter for one finds nothing. This surprises people arriving from any other engine.

Granting a role is not the same as granting SELECT

Privileges from a role are not active in some contexts, notably inside definer-rights PL/SQL. Direct object grants, as above, behave predictably.

A read-only login still shows everything

The user above stops writes. It does not stop someone reading every email address, card number and salary in the database, and it does not record who did. The console adds the other half: sensitive columns are detected and masked before the rows leave the server, unmasking is granted per column to named people, and every access is logged. Access Review answers "who can see what" across every source in one report, which is the question that is very hard to answer from a pile of grants.

Questions

How do I create a read-only user in Oracle?

Create the user, grant CREATE SESSION so it can connect at all, then grant SELECT on the specific objects it should read. Verified on Oracle Free 23: SELECT permitted, INSERT and DROP refused.

Do I need to grant on every table individually?

For precise access, yes, and that is usually the right answer. Where a schema should be readable wholesale, a role plus SELECT ANY TABLE is far broader than most people intend — the console's allowlist is a better place to draw that line.

More on Oracle

Other databases