Oracle DB
Oracle databases hold the operational core of many of the largest organisations in the Kingdom, usually behind applications with narrow licensing and narrower usability.
Oracle databases hold the operational core of many of the largest organisations in the Kingdom, usually behind applications with narrow licensing and narrower usability.
What Oracle DB holds, and why that matters here
Oracle Database underpins ERP, banking and large enterprise systems across the region. The data is high-value and the access is tightly controlled, which is appropriate — and which also means most people who need answers cannot get them directly.
The result is the familiar bottleneck: a small technical population fielding a constant stream of requests for individual facts.
- Enterprise application data — the operational record.
- Financial records — where finance systems run on it.
- Historical data — retained over long periods.
- Views and packages — the curated access already defined.
- Reference structures — the master data other systems depend on.
Questions Elbi can answer from an Oracle database
What is the current state?
A specific record described in plain language.
How many are pending?
A count without a report request.
What is the history?
Previous states and changes against a record.
Which are outside tolerance?
A filtered set summarised for a business reader.
What was the position at period end?
A historical figure, retrieved rather than reconstructed.
Does this exist?
Existence and basic state.
How Elbi reads from Oracle
- A user that owns nothingIn Oracle a user and its schema are the same thing, so the connection gets a user of its own with CREATE SESSION and no objects. It reads other schemas' views through object grants and cannot create anything itself.
- Views in a separate reporting schemaThe agreed views are created in a schema set aside for reporting rather than inside the application's schema. That matters under packaged ERP and banking systems, where the vendor's schema is best left untouched, and it gives reviewers one place to look.
- READ rather than SELECT on named viewsThe user is granted READ on each view. Unlike SELECT, READ does not allow rows to be locked with SELECT … FOR UPDATE, so a lookup can never hold up the application. System privileges such as SELECT ANY TABLE are never granted.
- Bind variables, not assembled SQLEvery lookup is a fixed statement with bind variables for the values a person supplies. That is safer, and it lets Oracle reuse the parsed statement instead of hard-parsing a new one for every question.
- A standby, where one is open for queriesWith Active Data Guard, a physical standby can serve read-only queries while staying in sync with the primary, which keeps lookups away from production. Active Data Guard is a separately licensed option, so check what your estate already has before planning around it.
- Arabic read in the right character setSome long-standing databases store Arabic in a legacy Arabic character set rather than Unicode. Reading them with the correct encoding is settled during deployment, so names come back as written instead of garbled.
Schemas, grants and what stays yours
| Direction of access | Read-only by grant: CREATE SESSION plus READ on named views, and nothing else. Writes belong in the applications that own the data and apply its business rules. |
|---|---|
| Who can see what | The grants define what the user can reach. The asker's identity decides what they are told, and where per-customer limits must also hold inside the database, Virtual Private Database policies — an Enterprise Edition feature — can enforce them. |
| Credentials | A database user with a password you set, or external authentication if your estate uses it, under a profile that limits its sessions. Locking the account stops new sessions at once, from your side and without involving us. |
| Where data goes | Values read from Oracle are used only for the reply they were requested for. Message content is destroyed within 24 hours, usually as the conversation ends, and none of it is given to an external AI service. |
| Audit | Unified Auditing can record this user's reads on the reporting views under a policy of their own, kept in the database's audit trail under your DBAs' control. |
| If it is unavailable | If the listener refuses the connection, the account is locked or a query exceeds its limits, the assistant reports that it could not get the answer and offers a person rather than estimating a figure. |
What the Oracle connection replaces
In organisations of this size the request queue is usually formalised — a reporting team, a ticket system, a turnaround measured in days. That formality is what makes small questions expensive: asking costs more than the answer is worth, so people either wait or guess.
An assistant with a curated read view changes the economics of small questions. Not the analytical work, which belongs where it is, but the individual facts that currently justify a ticket.
The governance position is straightforward because it is narrow: named lookups, read-only, scoped to what has been agreed, logged. That is a far easier proposition to approve than broad access.
Where Oracle lookups matter most
Large enterprise
Individual facts that currently require a report request.
Banking
Operational records behind tightly licensed applications.
Government
Long-retained data with narrow access.
Utilities and industry
Operational history from core systems.
Getting value from Oracle
Pull a few weeks of requests from whichever team runs queries for the business. Set aside the analytical work, which belongs where it is; what remains — individual facts about individual records — is the list to build views for.
Work with the application's owners rather than around them. Packaged systems such as Oracle E-Business Suite come with their own documented views and interfaces, and reading through those instead of the raw tables means the answers are more likely to survive the next upgrade.
Plan for period end. Finance and banking systems are busiest at month and quarter end, which is also when people ask the most questions. A standby for reads, or lookups restricted to indexed keys, keeps the assistant from competing with the close.
What connecting an Oracle database involves
- Agree the questions with the system ownerOracle databases under ERP or banking systems have owners with firm views on what may be read. Start with them, and with the list of questions, before anyone writes a view.
- Build the reporting schema and viewsCreate the views in a separate schema, reading from the application's tables or its supported views, and exposing only the columns each answer needs.
- Create the user and grant READCREATE USER with CREATE SESSION, a profile that limits sessions, and READ on each view. DBA_TAB_PRIVS and DBA_SYS_PRIVS will confirm it holds nothing more.
- Decide on a standbyIf Active Data Guard is licensed, point the connection at the standby; if not, confirm the lookups are light and well indexed enough for the primary.
- Create an audit policyDefine a Unified Auditing policy for the user's access to the reporting views and enable it before launch.
- Test, then launch narrowTry unknown references, other customers' records and Arabic names in different spellings, then launch with the few views that carry most of the volume.
Personal data in Oracle-backed systems
Oracle databases under banking, government and ERP systems carry some of the most sensitive personal data an organisation holds. Under the Saudi Personal Data Protection Law, and any sector rules that apply alongside it, the reporting schema is where minimisation is demonstrated: each view shows exactly which columns can leave the database.
Residency follows the database, and for these systems it is usually already fixed by regulation and internal policy. The connection reads the data where it is and moves nothing; record the location with the list of views.
For a reviewer, the grant list and the Unified Auditing trail answer what could be read and what was — both held in your database, under your DBAs.
What organisations typically see
How Oracle data is usually reached
Oracle's own options include Oracle APEX for building internal applications over the database, Oracle Analytics for reporting, and Oracle Digital Assistant for building conversational interfaces. On Autonomous Database, Select AI turns natural-language questions into SQL for people working with the data.
Many organisations meet the demand with a reporting team and a ticket queue. It is controlled and auditable, and it makes a fact that takes a moment to read cost days of waiting.
Giving more people application logins is the other route, and in Oracle-based ERP it is often constrained by licensing as much as by security.
The recurring mistake is a reporting account granted SELECT ANY TABLE because it was quicker than writing individual grants. It turns a narrow connection into read access across the application schemas in the database.
Common questions about the Oracle connection
Named parameterised lookups against curated structures, scoped during deployment. It is not arbitrary querying against production.
No. Read-only by default and by recommendation.
That depends on your agreement with Oracle rather than on us. Under user-based licence metrics, people served through an intermediate system can still count, so confirm the position with whoever manages your Oracle licences before go-live.
Yes, and for packaged systems it usually should. Reading through the application's supported views keeps the connection in line with how the vendor expects the data to be used, and tends to survive upgrades better than reading base tables.
No. It needs CREATE SESSION and READ on named views. A request for a DBA role, SELECT ANY TABLE or catalogue roles should be refused.
Both are fine. On RAC the connection uses a database service like any other client; in a multitenant database the user is created in the pluggable database that holds the data, not in the root container.
Connect it to your own systems
A working assistant against your own records, in both languages.