Getting Started with Select AI in Oracle Autonomous Database

Introduction

Most of us are used to querying enterprise database data by writing structured SQL. However, that workflow assumes a foundational understanding of relational design, table joins, and SQL syntax—a barrier for many business stakeholders. With the advent of generative AI, Oracle has fundamentally shifted how users interact with data.

Features like Oracle Autonomous Database Select AI democratize data access by allowing business teams and non-technical users to converse with data using natural language. Instead of waiting for a developer to write a custom query, a user can simply ask: “Give me the top 5 suppliers by purchase volume this quarter” and let the database handle the translation, optimization, and execution behind the scenes.

Inspired by some excellent hands-on scenarios in Oracle LiveLabs, I wanted to break down how Select AI functions under the hood and provide a clean, production-minded starting point for architects looking to implement it.

 

What is Select AI?

To understand Select AI, it helps to look at it as an intelligent bridge connecting three distinct components:

1. The User Prompt: A question written in plain English.

2. Database Schema Metadata: The allowed tables, views, and data dictionaries available for questioning.

3. The Generative AI Model: A Large Language Model (LLM)—such as OCI Generative AI or a supported third-party provider—that translates the prompt into semantic SQL.

[Plain English Prompt] ──> [Select AI + Schema Context] ──> [LLM Translation] ──> [Optimized SQL Execution]

By keeping the LLM outside of the data storage layer, Select AI ensures that your core data never leaves the secure boundaries of the Oracle Autonomous Database; only the metadata (table and column names) is passed to the model to generate the query.

The Architecture Flow

Setting up a natural-language query interface follows a predictable, five-step lifecycle:

Step 1: Credential Provisioning: Establish secure, IAM-based or API-key credentials to authenticate against the AI provider.

Step 2: Profile Definition: Construct a Select AI profile defining the target LLM, region, and the precise boundary of allowed database objects.

Step 3: Session Initialization: Activate the profile within the user session and validate provider connectivity.

Step 4: Natural Language Execution: Submit plain-text prompts directly via SQL interfaces.

Step 5: Review & Narration: Audit the generated SQL or leverage the LLM to narrate the results back to the user.

Step 1: Establish the AI Credential

Before the database can call an external LLM, it requires a secure credential. If you are using OCI Generative AI, this typically utilizes OCI resource principals or native cloud security tokens. In an enterprise environment, this identity is managed securely via vaults or database secret management, ensuring API keys are never exposed in plaintext code.

Step 2: Create a Select AI Profile

The AI profile is the governance gate. It tells Autonomous Database exactly which tables or views the LLM is allowed to see. As a best practice, limit this object list to only the specific reporting layer or semantic views required for the business use case. Including an entire OLTP schema will confuse the model and degrade accuracy.

Here is a deployment script configuring a profile against an OCI Generative AI endpoint for a supplier procurement use case:

BEGIN
DBMS_CLOUD_AI.DROP_PROFILE(
    	profile_name => 'genai',
	force        => TRUE
);

DBMS_CLOUD_AI.CREATE_PROFILE(
	profile_name => 'PROCUR_AI_PROFILE',
	attributes   => '{
		"provider": "oci",
		"credential_name": "OCI_AI_CREDENTIAL",
		"region": "us-chicago-1",
		"comments": "true",
		"object_list": [
			{"owner": "SUPPLIERS", "name": "SUPPLIERS"},
			{"owner": "SUPPLIERS", "name": "PURCHASE_ORDERS"},
			{"owner": "SUPPLIERS", "name": "PURCHASE_ORDER_LINES"},
			{"owner": "SUPPLIERS", "name": "INVOICES"}
		]
	}'
);

END;
/

For beginners, the most important part of this example is the object_list. This list defines the tables Select AI can consider when interpreting your natural language question. Keeping this list focused usually leads to better, more predictable results.

Step 3: Initialize and Test the Connection

With the profile created, you must explicitly set it for the active database session. This ensures that subsequent natural language commands inherit the correct security and metadata boundaries.

BEGIN
DBMS_CLOUD_AI.SET_PROFILE(profile_name => 'PROCUR_AI_PROFILE');
END;
/

Before testing against your corporate data, it is a good habit to run a basic sanity check using the chat keyword to verify that the database can successfully negotiate the handshake with the remote LLM endpoint without querying local tables:

SELECT DBMS_CLOUD_AI.GENERATE(
   prompt       => 'What is the difference between an inner join and an outer join?',
   profile_name => 'PROCUR_AI_PROFILE',
   action       => 'chat'
) FROM dual;

Step 4 & 5: Conversing with Your Enterprise Data

Once verified, you can run actual queries. In modern SQL interfaces (like SQL Developer Web or cloud-based worksheets), you can use the AI prefix to signal a natural language query directly.

For example, a business analyst can run:

SELECT AI show me the total invoice amount by supplier for the last 6 months;

Select AI interprets the question, looks at the metadata for the allowed tables, generates SQL, and returns the result. From a user perspective, the experience feels much closer to asking a question than writing a query from scratch.

For example, the generated SQL for that question could look conceptually like this:

You can also see the underlying SQL it ran using showsql function like this SELECT AI showsql show me the total invoice amount by supplier for the last 6 months)

Conclusion

Oracle Autonomous Database Select AI bridges the gap between complex relational schemas and the business users who rely on that data. By treating the AI configuration as a governed profile of metadata rather than exposing raw data blocks, Oracle delivers a secure framework that fits cleanly into enterprise architecture standards. If you are getting started, try setting up targeted database views, enrich them with data dictionary comments, and watch how effectively your database handles natural language.