Pakistan's First Oracle Blog

icon), then paste everything below this comment.-->

A refrigerated truck rarely fails with a bang. It drifts. The trick is noticing the drift while the cargo is still safe.

A Tuesday Night on the Highway

Picture a fleet of refrigerated trucks carrying vaccines, dairy, and frozen food overnight. Each truck produces a steady stream of readings: cargo temperature, compressor current, door-open time, vibration, and fuel use. Those readings usually sit in separate places, such as telematics portals, maintenance systems, and spreadsheets.

When someone has to hunt across all of them, problems get found late. This post sketches how a fleet operator could use Oracle Cloud Infrastructure (OCI) and Oracle AI Data Platform to connect those signals and move from reacting to predicting. It is an adapted scenario based on a published Oracle reference approach for industrial IoT, not a customer case.

The Cast of Oracle Services Oracle AI Data Platform

The backbone. It brings ingestion, processing, storage, analytics, and AI into one connected foundation, so raw truck telemetry becomes curated data that other teams can reuse.

OCI Streaming

The intake pipe. Spark publishes sensor events to it through its Apache Kafka-compatible endpoint, which moves high-volume readings toward processing.

Spark on OCI

The cleanup crew. It validates and enriches incoming data and standardizes timestamps, units, and measurements, so a Fahrenheit reading from one truck and a Celsius reading from another do not get mixed up.

Oracle Analytics Cloud

The control room screen. Dispatchers and maintenance planners see trends, anomaly flags, and forecasts in shared dashboards.

Oracle Fusion Data Intelligence

The memory. It can combine maintenance history and work-order data with the operational picture, so a strange reading can be compared with what was last repaired on that unit.

Following One Reading from Truck to Technician

1. Sense. Sensors on the trailer capture temperature, compressor behavior, and door activity.
2. Stream. Events flow into OCI Streaming through the Kafka-compatible endpoint.
3. Prepare. Spark checks, enriches, and standardizes the data.
4. Store. Object Storage and data-lake layers keep both current and historical readings.
5. Learn. Models flag unusual behavior and forecast where signals are heading.
6. Show and alert. Dashboards and notifications reach the people who can act.

Good predictions depend on good data first. The machine learning only works if the pipeline underneath it is reliable and consistent.

Smarter Than a Fixed Alarm

A simple threshold alarm only fires after the temperature crosses a line. Anomaly detection looks at patterns across signals, such as a compressor drawing more current while the cargo temperature creeps upward. That pattern can deserve attention even though no single reading has crossed a limit yet.

Forecasting adds time. If a signal is expected to keep moving the wrong way, planners get a chance to schedule a check at the next depot instead of dealing with a spoiled load on the road.

What a Good Alert Looks Like

An alert can name the affected signal, the truck or trailer, and the time of the event. The people receiving it should treat it as a prompt to look closer, not as proof that something has broken. They confirm against the dashboard trend, decide whether to inspect, and record what they decided.

Two Screens That Do the Heavy Lifting Fleet health view in Oracle Analytics Cloud

Dashboards can combine sensor trends, anomaly indicators, forecasts, maintenance dates, and work-order readiness. One page answers the question: which trailers need eyes on them first?

Maintenance context in Fusion Data Intelligence

Teams can identify units with higher anomaly rates, compare predicted maintenance dates with scheduled ones, and review asset trends. That helps with prioritizing work and with efforts to limit unplanned downtime.

Ask Questions in Plain Language

The same curated data can feed AI-assisted reporting. A manager could ask which routes showed the most door-open anomalies this week and explore possible causes without waiting for a separate report. Oracle also notes that Oracle Analytics Cloud data models can be reached through supported MCP clients for natural-language and developer workflows. The MCP tools are described as a preview feature, so review the documentation before testing.

Five Things to Settle Before Launch

• Data rules. Agree on expected ranges, units, timestamp conventions, and what happens when a sensor goes quiet.
• Who owns each alert. Name the responsible team, severity levels, notification channel, and escalation path.
• Model upkeep. Track false alarms and misses, watch for drift, and decide when to retrain or roll back.
• Access control. Consider least-privilege access, OCI IAM policies, compartment boundaries, encryption, network controls, and audit logging.
• A human in the loop. Decide how alerts get verified, how decisions are recorded, and how outcomes are reviewed.

Where to Go Next

Start by reading the documentation for OCI Streaming, Oracle AI Data Platform, Oracle Analytics Cloud, and Oracle Fusion Data Intelligence. Then test the pipeline, access controls, model monitoring, and response workflow against your own fleet and your own cargo rules.

The Takeaway

The value is not in collecting more data. It is in connecting what you already collect so the right person sees the right signal early enough to act. Done well, that points toward fewer unplanned breakdowns, steadier cargo quality, and calmer nights for dispatch.

Leaderboards tell you who won a contest. They do not tell you who will survive your Monday morning workload.

The Trap of Starting With a Model Name

A lot of AI projects kick off by checking rankings and picking whatever is trending. The result often shines in a demo, then stumbles when real volume, many simultaneous users, and hard business deadlines show up. A sturdier approach starts somewhere else entirely: with the work. What must the system produce, how quickly, how accurate must it be, and how much human review already happens afterward?

What follows is a practical way to answer those questions, drawn from a large request-for-proposal (RFP) automation effort that ran on Oracle Cloud Infrastructure Generative AI.

Write Down the Constraints First

Before touching an optimizer or shortlisting a model, put numbers and facts behind these questions:

1. How many items need processing in one batch or one day?
2. What turnaround time is acceptable?
3. How much human checking still follows the model's answer?
4. How tightly must answers stay anchored to source documents?
5. What level of concurrency will production realistically see?

Honest answers here cut the options down faster than any benchmark ever will.

Training Methods: Match the Tool to the Terrain

The optimizer that adjusts weights during training shapes how long training takes, how stable it is, and how good the result becomes. Think of it as choosing a vehicle for the road ahead.

Steady and predictable suits smaller models and tabular data. Adaptive step sizing suits big transformer-style models. History-aware methods suit data that unfolds in sequence.

Simple, stable updates are a good fit when predictable behavior matters more than raw speed. Adaptive methods tune their own step sizes, which tends to speed up convergence on large transformer models and often lowers total compute cost. Methods that weigh recent history can help when the data has a strong sequential flavor.

Even if your organization only consumes a pre-trained model, this still matters. Upstream training choices shape how the model behaves on your data, so look at the algorithm family alongside your intended production use.

Choosing a Model for Your Workload

There is no universal winner. Retrieval-heavy tasks that must stay faithful to internal documents lean toward models built for grounded generation. High-volume batch jobs that can tolerate a few gaps lean toward throughput-focused models. Multimodal needs, long-document analysis, or on-premises customization each point somewhere different.

A reliable test: take a representative slice of your real workload, run it on two or three candidates, and measure both quality and elapsed time under the same network and concurrency conditions production will have.

A Real Test Run: What the RFP Project Revealed

In the evaluated project, a large set of enterprise questions was processed across different network paths, shared and dedicated infrastructure, and single-user and concurrent loads.

One model gave thoroughly grounded answers but needed about ninety minutes per batch. A second model finished the same volume in a fraction of that time, and most of its responses were still usable after a short human review that the existing process already included.

Surprises Along the Way

• More concurrent users did not always mean more total throughput. Rate limits in the managed service sometimes made serialized runs the more efficient choice.
• Many "not found" answers came from missing content in the knowledge base, not from the model.
• Detailed regional instructions in prompts sometimes caused language drift. Simpler, clearer prompts gave steadier results.

The team picked the faster model. Downstream review already covered coverage gaps, and the shorter cycle meant more batches per day. Workflow fit decided it, not a universal ranking.

Let the Constraints Shape the Architecture

Once the operational needs are clear, the surrounding design falls into place. Routing logic, retrieval settings, fallback handling, and concurrency limits become deliberate choices instead of afterthoughts. Swapping models without revisiting these pieces rarely fixes the real problem.

Teams that begin with the outcome they need, the latency they can live with, and the review steps already in place usually reach a working system sooner than teams that begin with a favorite model.

Your Next Five Moves

1. Document volume, latency target, and review process for your specific use case.
2. Run a side-by-side comparison on a representative sample, under realistic network and load conditions.
3. Check data coverage and retrieval quality before blaming the model for gaps.
4. Treat prompt wording and concurrency settings as dials you can tune, not fixed constants.
5. Measure end-to-end cycle time and human effort, not just model-level scores.

The Bottom Line

Enterprise AI works when the tools and methods line up with the work that must get done. The strongest systems scale reliably inside the operational environment they live in, no matter which model sits at the center.

What if your data could live in the right country, survive a regional outage, and still look like one database to your application?

The Idea in Plain Words

Oracle Globally Distributed AI Database is a single logical database that spreads and replicates data across nodes, regions, and countries. Developers work with it as one database. Behind the scenes, Oracle decides where each piece of data lives.

Oracle positions it for always-on architectures, high performance, and data residency rules. Applications keep the converged capabilities of Oracle AI Database, including relational, AI vector, JSON, Graph, and Spatial data.

Where You Can Run It

Oracle lists several deployment options:

• Globally Distributed Autonomous AI Database on OCI, a fully automated option.
• Globally Distributed Exadata Database on Exascale Infrastructure on OCI.
• Oracle AI Database services on OCI in multicloud environments.
• Oracle AI Database Enterprise Edition in your own data center.

The capabilities are built into Oracle AI Database Enterprise Edition, so the same approach works wherever it is deployed.

Sharding Without the Manual Work

Sharding means splitting data across several databases. Doing it by hand is painful. Oracle says its service automates sharding and resharding, and rebalances data to keep workloads even.

Oracle describes six data distribution methods. One example is composite sharding, which uses two levels of sharding with different methods and keys. The goal is to place data close to where it is needed for low latency, availability, or residency.

Raft Replication for Fast Failover

Raft is a consensus protocol for replicating logs across nodes. Oracle uses it in an active-active-active design. Its stated goals are failover within seconds and no data loss during outages.

Raft replication is available with Oracle AI Database 26ai. Oracle also says Globally Distributed AI Database can be used with Oracle Database 19c to gain Raft replication. Oracle Data Guard can be added as another replication choice on the Autonomous service.

Data Residency Made Practical

Many regulations say certain data must stay in a given country. With this database, you set policies by geography for data, replicas, backups, and encryption keys. Specific shards can sit in-country while the application tier stays central.

Oracle quotes Munich Re HealthTech saying the service helps them meet residency rules by distributing data across countries, transparently to application users.

No Code Changes

Oracle says existing Oracle AI Database applications can start using a distributed database without modification. The client drivers support it natively, and developers keep strong consistency and full SQL.

Where It Fits

• Global apps that need low latency for users on every continent.
• Financial systems that cannot afford to lose transactions.
• Regulated industries with strict in-country storage rules.
• AI workloads that combine vector search with business data.

Before You Start

1. List which data must stay in which country.
2. Choose a sharding key that matches how your data is accessed.
3. Pick a replication method for your failover and consistency needs.
4. Test failover and resharding under realistic load.
5. Verify current feature and version support in Oracle's documentation.

The Bottom Line

Globally Distributed AI Database aims to give teams global scale, high availability, and residency control without rewriting applications. Oracle's claims are strong, so run your own workload tests to confirm them for your environment.

An agent that can reach everything is a liability. An agent that can reach exactly what it needs is a colleague you can trust.

The Problem in One Sentence

A single chat with an AI assistant can touch several systems: it fetches a sales report, then drafts follow-up tasks in another app. Every one of those hops needs its own yes or no from an identity system. Oracle Cloud Infrastructure IAM now offers building blocks that handle this for Model Context Protocol (MCP) servers.

Why MCP Needs a Gatekeeper

MCP is the common language agents use to find and call tools in databases, APIs, and business software. That convenience cuts both ways. Without guardrails, a well-meaning agent can wander into places it should never go. OCI IAM acts as the gatekeeper: it approves which clients are allowed, narrows which resources they can touch, and signs off on actions that happen downstream.

How the Handshake Works

1. Discover. The MCP client reads the server's Protected Resource Metadata and learns where the authorization and token endpoints live. No hard-coded settings needed.
2. Identify. The client presents its identity through a metadata document (explained below).
3. Authenticate. The user signs in using the authorization-code flow with PKCE.
4. Receive a scoped token. OCI IAM issues an access token matching the requested MCP resource and scopes.
5. Verify. The MCP server checks validity, audience, and scopes before running any tool.

Client Onboarding Without the Paperwork

With Client ID Metadata Documents, an application simply hosts a small JSON file at a public HTTPS address and uses that address as its client ID. OCI IAM retrieves and validates the file, so nobody has to register the same client over and over.

Two Locks, Two Keys AllowlistWhere it livesWhat it decides Metadata locationsIdentity domainWhich sources of client documents are trusted Approved clientsResource applicationWhich clients may call that specific protected resource

The result: a client can be cleared for sales reporting and still be locked out of every other application.

Tokens That Know Their Limits

For interactive use, a public client runs the authorization-code flow with Proof Key for Code Exchange. After the user logs in and the client submits its code challenge, OCI IAM returns a token whose audience and scopes fit the requested MCP resource. Read-only report access stays separate from the right to modify data, and the token never exceeds what the administrator set up.

When One App Is Not Enough: Cross-App Access

Suppose the agent must now act in a second system. OCI IAM handles this with an Identity Assertion JWT Authorization Grant:

• A confidential client in the source domain trades the user's ID token for a signed intermediate grant.
• A second confidential client redeems that grant at the target domain.
• The target domain maps the user, applies its own policies, and issues a brand new access token for its API.

Two things stand out. The interactive client never handles confidential credentials, and each domain keeps full authority over its own rules. The sales app, for example, still decides which tasks that user may create.

Ask an HR assistant about parental leave and nothing bad happens. Ask it for a coworker's home address or the history of complaints against them, and suddenly the same assistant becomes a privacy risk. Once a generative AI is wired into HR records, every single prompt deserves a quick look before the main model sees it.

The fix described here is simple: put a compact, specialized classifier in front of the main HR model. It reads each request first, then decides whether to let it through, flag it, or shut it down.

Sorting Every Request Into One of Three Buckets

The classifier labels each prompt as Normal, Caution, or Restricted. Here is what each one means in plain terms.

Normal covers the everyday stuff: policy lookups, benefits, how a process works. These sail straight through to the main model with no friction.

Caution applies to requests that brush against sensitive ground, such as salary ranges for a whole team or who reports to whom. The system can attach a warning or give a trimmed-down answer.

Restricted is for blunt attempts to pull personal contact details, disciplinary files, or one person's pay. Those are stopped before the main model ever sees them.

The payoff is that routine questions stay quick while obvious grabs for confidential data hit a wall.

Following One Request From Start to Finish

An employee types a question into a portal, a chat window, or an API call. Before anything else happens, the classifier reads it and returns a label with a confidence score. The application then acts on that result: pass the prompt along, add a warning, or send back a refusal. Each decision gets logged, which gives security and compliance teams a trail to review later.

Since the classifier is small, the extra wait for the user is barely noticeable.

Picking a Model and Teaching It Your Rules

A compact, safety-oriented model is a good starting point. Fine-tune it on HR-flavored examples and it learns to tell a harmless policy question from an attempt to dig up private details. Keep the training data shaped like real traffic: mostly safe prompts, a smaller group of borderline ones, and a few clearly restricted ones. That realistic balance stops the model from crying wolf on legitimate questions.

Fine-tuning uses adapters, so only a thin layer of extra weights is trained and stored. The base model stays frozen. Memory use stays low, and updating the safety rules later does not mean starting from scratch.

Wiring It Into a Live System

In production, you load the classifier once and expose it as a small service. A call looks roughly like this:

from transformers import pipeline

safety_pipe = pipeline(
    "text-generation",
    model="./hr_safety_adapter",
    device_map="auto"
)

def check_prompt(user_text):
    raw = safety_pipe(user_text, max_new_tokens=15)[0]["generated_text"]
    # Parse the generated label and confidence from raw output
    return parse_label(raw)

Place the service behind an API gateway. Keep the model files and adapter in object storage and pull them in when the container boots. Send logs and metrics to your monitoring stack so odd patterns show up fast.

Shipping It: Six Steps

1. Bundle the classifier and adapter into a container image.
2. Push that image to a container registry.
3. Run it on a managed container service or a Kubernetes cluster.
4. Keep model artifacts in object storage and load them at startup.
5. Send all traffic through an API gateway that enforces authentication.
6. Ship decision logs to a central logging service for review.

Lessons Worth Borrowing

Sharp label definitions beat a bigger pile of training examples.

Preserving the real-world mix of safe and sensitive requests cuts false alarms. It also helps to treat the model as a text generator rather than a pure classifier, since that is how it actually produces its labels. And once the training data is swapped out, the same pattern carries over to other sensitive domains.

The Short Version

A small, domain-tuned safety model in front of an HR assistant catches risky prompts before they reach the core system. Latency stays low, the infrastructure is modest, and every decision can be audited. The same design suits any setting where employee or customer data must stay protected without giving up useful AI features.

What You Are Actually Creating

In the OCI Console, a Globally Distributed Autonomous AI Database is a single resource that holds the whole configuration: the nodes (shards), the catalog, the data distribution method, the replication method, connection details, and backup settings. You start from the service home page and select Create database.

Settings You Cannot Change

Two fields are fixed. Only Dedicated Infrastructure is supported as the deployment type, and only Transaction Processing is supported as the workload type. For the database version, you choose between 19c and 26ai.

The Big Decision: Distribution and Replication

This is the most important step, because the replication type is set once and cannot be changed later.

Three ways to distribute data

• Automated: data is spread across nodes using partitioning by consistent hash, evenly and randomly.
• User managed: you map data to specific nodes yourself. This suits cases where performance or regulation requires certain data on a particular node, and you want full control over moving it.
• Multi-Level: you create several data spaces for different subsets of a table that is hash partitioned. A data space is a set of nodes holding a range or list of key values. The documentation says this gives better load balancing than User managed distribution.

Two ways to replicate

• Raft: replication units made of chunks are distributed automatically across nodes. The system handles chunk assignment, movement, and balancing when you scale. User managed distribution is not available with Raft.
• Data Guard: a node-level approach that creates a standby database for each node. You do not set it up in the initial deployment. You configure the replicas after the database is created.

The Catalog Comes Preconfigured

The catalog appears already filled in, and you can change it with Edit in the Actions menu. Raft does not apply to the catalog. Protect it by adding Data Guard replication after creation.

Locking It Down: Credentials and Encryption

You set an ADMIN password that can access every database in the configuration, including the catalog.

For encryption, you choose between OCI Vault Service and Oracle Key Vault. The rules depend on your distribution type:

• With Automated distribution, all nodes share the same vault and key (OCI Vault) or the same OKV endpoint group name (Oracle Key Vault).
• With User managed distribution, each node can use the same or different key details, and this is optional.
• With Multi-Level distribution, all nodes within a data space share the same key details.

Oracle's guidance is simple: use OCI Vault if your nodes sit in fewer than three regions, and use Oracle Key Vault if they span three or more. You cannot switch between the two types once the database exists.

Network, Characters, and Ports

Pick the private endpoint you configured earlier. For character sets, AL32UTF8 is recommended by default, with AL16UTF16 as the national character set. Then enter the listener port, the local ONS port, and the remote ONS port. The remote ONS port and the TLS port must each be unique to this database. Do not reuse a number from another one until its delete operation has fully finished.

Optional Extras Under Advanced Options

You can pass settings to enable automatic backups to Object Store. You can also attach a network security group to the virtual cloud network that hosts the GSMs. The NSG must already exist.

Validate, Create, Wait

1. Select Validate to run checks against your configuration.
2. Fix any errors, then select Create.
3. Watch the State column and the Work request tab for progress.
4. Wait for the node status to show Available.

Expect a wait. Creation includes host procurement, software installation, and generating certificates for the GSMs.

One Warning to Remember

After creation, do not move the vaults and keys, or the database will stop working.

Quick Recap of the Permanent Choices

Replication type, encryption key type, and the dedicated infrastructure and transaction processing options are all fixed once set. Decide them on paper first, then build.

Many teams begin an AI project by looking at leaderboards or popular model names. That approach often leads to systems that look strong in tests but struggle once real volume, concurrency, and business deadlines appear. The more reliable path starts with the work itself: what the system must produce, how fast it must run, how accurate the answers need to be, and how much human review already exists downstream.

This post outlines a practical way to make those choices, using lessons from a large-scale request-for-proposal automation effort that ran on Oracle Cloud Infrastructure Generative AI.

Start with the Operational Requirements

Before selecting an optimizer or a model, list the constraints that matter for the actual process:

• How many items must be processed in a single batch or day?
• What is an acceptable turnaround time?
• How much human review will still occur after the model responds?
• How important is it that every answer stay tightly grounded in source documents?
• What concurrency levels are realistic in production?

These answers narrow the field more effectively than any benchmark score.

Matching Training Algorithms to the Data and Goal

The optimizer that updates model weights during training has a direct effect on training time, stability, and final quality. Different optimizers suit different situations:

• Simple, stable updates work well for smaller models or tabular data where predictable behavior matters more than raw speed.
• Adaptive methods that adjust step sizes automatically tend to converge faster on large transformer-style models and often reduce overall compute cost.
• Methods that emphasize recent history can help when the data has a strong sequential character.

The same principle carries forward when an organization consumes a pre-trained model. The training choices made upstream shape how the model behaves on enterprise data, so the selection process should consider both the algorithm family and the intended production use.

Selecting a Model for the Workload

No single model is best for every task. Retrieval-heavy work that must stay faithful to internal documents often favors models designed around grounded generation. High-volume batch jobs that tolerate occasional gaps may favor models optimized for throughput. Multimodal needs, long-document analysis, or on-premises customization each point toward different options available on the platform.

A useful test is to run a representative slice of the real workload on two or three candidate models and measure both quality and elapsed time under the same network and concurrency conditions that production will face.

What the RFP Automation Effort Showed

In the evaluated project, a large set of enterprise questions was processed under different network paths, shared versus dedicated infrastructure, and single-user versus concurrent loads. One model produced thoroughly grounded answers but required roughly ninety minutes per batch. A second model completed the same volume in a fraction of that time, with the majority of responses still usable after a short human review step that was already part of the existing process.

Several practical limits appeared during testing:

• Adding concurrent users did not always increase overall throughput; rate limits in the managed service sometimes made serialized runs more efficient.
• A large number of “not found” answers traced back to missing content in the knowledge base rather than to the model itself.
• Detailed regional instructions in prompts occasionally caused language drift; simpler, clearer prompts improved consistency.

The team ultimately selected the faster model because the downstream review process already covered coverage gaps, and the shorter cycle time increased the number of batches that could be handled each day. The choice was driven by workflow fit, not by a universal ranking.

Design the Workflow Around the Constraints

Once the operational needs are clear, the supporting architecture follows naturally. Routing logic, retrieval configuration, fallback handling, and concurrency limits become part of the design rather than afterthoughts. Swapping models without adjusting these elements rarely solves the underlying problem.

Organizations that begin by defining the required outcome, acceptable latency, and existing review steps tend to reach a workable system faster than those that start with a preferred model name.

Practical Next Steps

• Document the volume, latency target, and review process for the specific use case.
• Run a side-by-side evaluation on a representative sample under realistic network and load conditions.
• Inspect data coverage and retrieval quality before attributing gaps to the model.
• Treat prompt wording and concurrency settings as tunable parts of the system, not fixed constants.
• Measure end-to-end cycle time and human effort, not only model-level scores.

Enterprise AI succeeds when the chosen tools and methods line up with the actual work that must be completed. The strongest systems are those that scale reliably inside the existing operational environment, regardless of which model sits at the center.

SQL injection and credential misuse remain serious threats to database security. Oracle SQL Firewall offers a practical way to defend against these risks by allowing only approved SQL statements and trusted connection paths for each database user.

Instead of relying solely on application-level controls, SQL Firewall operates directly inside the database kernel. This makes it difficult to bypass and gives you fine-grained control over what each user can do.

How SQL Firewall Works

SQL Firewall uses an allow-list approach. You first let it observe normal activity for a user, then create a policy that defines exactly which SQL statements and connection details are permitted. Anything outside that policy triggers a violation that can be logged or blocked in real time.

It evaluates both the SQL statement itself and the context in which it runs, including the client IP address, operating system user, and program name. This helps protect against stolen credentials and unexpected access paths.

Key Benefits in Practice

• Inspects every SQL statement, including those generated inside PL/SQL
• Works whether connections are local or remote, encrypted or not
• Gives you the choice to log violations only or actively block them
• Applies per database user, making it easy to protect application accounts or individual users
• Integrates well with other Oracle security features like Database Vault and auditing

Setting Up SQL Firewall - A Practical Approach

Here is a straightforward way to implement SQL Firewall for an application service account.

Step 1: Enable SQL Firewall

EXEC DBMS_SQL_FIREWALL.ENABLE;

Step 2: Start Capturing Normal Activity

Begin recording what the target user typically does. This example captures activity for an application user named APP:

BEGIN
  DBMS_SQL_FIREWALL.CREATE_CAPTURE(
    username       => 'APP',
    top_level_only => TRUE,
    start_capture  => TRUE
  );
END;
/

Let the application run normally for a sufficient period so the firewall learns the expected SQL patterns and connection details.

Step 3: Review What Was Captured

Check the captured data to confirm it covers the expected workload:

SELECT SQL_TEXT 
FROM DBA_SQL_FIREWALL_CAPTURE_LOGS 
WHERE USERNAME = 'APP';

Step 4: Generate the Allow-List Policy

Once you are satisfied with the captured data, create the policy:

EXEC DBMS_SQL_FIREWALL.GENERATE_ALLOW_LIST('APP');

You can review the allowed SQL statements and connection contexts using the DBA_SQL_FIREWALL_ALLOWED_* views.

Step 5: Enable Enforcement

Activate protection for the user. This example enforces allowed SQL statements and blocks violations:

BEGIN
  DBMS_SQL_FIREWALL.ENABLE_ALLOW_LIST(
    username => 'APP',
    enforce  => DBMS_SQL_FIREWALL.ENFORCE_SQL,
    block    => TRUE
  );
END;
/

You can choose to enforce SQL statements, connection context, or both. You can also decide whether to block or only log violations.

Monitoring and Ongoing Management

Review violations regularly using this query:

SELECT SQL_TEXT, FIREWALL_ACTION, IP_ADDRESS, CAUSE, OCCURRED_AT
FROM DBA_SQL_FIREWALL_VIOLATIONS 
WHERE USERNAME = 'APP'
ORDER BY OCCURRED_AT DESC;

Periodically clean up old violation records and consider exporting policies using Data Pump for backup or movement between environments.

Important Considerations

• SQL Firewall only captures statements that execute successfully
• It normalizes SQL by replacing literal values before storing signatures
• Connection context is checked at session creation time
• You can add new allowed entries later from either the capture log or violation log
• Existing sessions are not terminated when you first enable a policy

When to Use SQL Firewall

This feature works especially well for:

• Protecting application service accounts that run a known set of SQL statements
• Adding an extra layer of defense for sensitive users such as reporting accounts or DBAs
• Quickly restricting direct database access to known IP addresses or programs
• Detecting and responding to potential SQL injection attempts in real time

Final Thoughts

Oracle SQL Firewall provides a practical, database-native way to enforce least-privilege access at the SQL level. By combining allow-listing of both statements and connection contexts, it helps reduce the attack surface without requiring major changes to your applications.

Start with a focused rollout on your most critical application accounts, review the captured activity carefully, and gradually expand protection across your environment.

Organizations running Oracle workloads in AWS now have a powerful new option. Oracle Autonomous AI Database Serverless is generally available on Oracle AI Database@AWS. This allows teams to deploy a completely self-managing Oracle database directly through the AWS Console while using their existing AWS spending commitments.

The service handles patching, performance tuning, scaling, and security updates automatically, so teams spend less time on routine maintenance and more time on strategic initiatives.

The Shift Toward Hands-Off Database Management

Many companies want the benefits of automation without moving away from AWS. This release delivers exactly that. You get Oracle’s most advanced autonomous database technology running inside AWS data centers, with the same tools and purchasing experience your teams already use.

Independent research has shown strong returns for organizations adopting this approach, including major gains in team productivity and sharp reductions in unexpected outages. Those advantages are now available without leaving the AWS environment.

Reduced Day-to-Day Database Work

The service takes care of many tasks that traditionally require manual effort:

• Patches and upgrades are applied automatically with no downtime
• Indexing and query optimization happen continuously in the background
• Compute and storage scale independently based on actual demand
• Security updates are managed without scheduling windows

This automation helps database administrators and infrastructure teams become significantly more productive. They can shift focus toward architecture, data strategy, and innovation instead of ongoing maintenance.

Support for Different Workload Needs in One Service

Rather than running separate systems for different requirements, a single instance can handle multiple patterns:

• High-volume transactional applications and mixed workloads
• Analytics, data warehousing, and lakehouse scenarios with support for open table formats
• Document-centric applications using familiar JSON interfaces
• Rapid application development through low-code tools with built-in AI features

Reliable Protection for Important Systems

Mission-critical applications need strong uptime guarantees. The service includes:

• A 99.995 percent availability commitment
• Disaster recovery options across AWS regions
• Local high availability with automatic failover between availability zones
• Fully managed backups stored in Amazon S3

Deep Integration with AWS Services

Because the database runs on Oracle infrastructure inside AWS data centers, connectivity to other AWS services is fast and straightforward. Key integrations include:

• Automated backups landing in Amazon S3 with options for immutability
• Encryption using customer-managed keys through AWS KMS
• Zero-ETL data movement into Amazon Redshift for analytics
• Native metrics and events flowing into CloudWatch and EventBridge
• Provisioning and management through the AWS Console, APIs, and CloudFormation templates

Best Fit Scenarios

This offering works especially well when teams want to:

• Bring existing Oracle applications into AWS with limited changes
• Lower the operational load on database and infrastructure teams
• Build AI applications that need vector search and natural language capabilities
• Consolidate different workload types onto a single managed platform

Availability and Next Steps

The service is available now in the US East (N. Virginia) and US West (Oregon) regions. Both Oracle AI Database 26ai and 19c are supported, along with flexible licensing models.

Teams already comfortable with AWS tools can start exploring the service through familiar interfaces while taking advantage of Oracle’s automation and resilience features.

Creating a reliable retrieval-augmented generation (RAG) system usually involves a lot of boilerplate. With the langchain-oracledb integration, you can build a complete pipeline; document loading, chunking, vector storage, hybrid search, semantic caching, and conversation memory; in a clean and compact way.

This guide walks you through a practical, end-to-end implementation using Oracle AI Database as the single source of truth for vectors, text, cache, and history.

Why Oracle AI Database + LangChain?

Instead of juggling multiple systems (vector database + cache + message store), everything lives inside Oracle AI Database. This simplifies architecture, improves consistency, and gives you enterprise-grade features like transactions and security out of the box.

High-Level Architecture

Here’s how the pieces connect:

• Ingestion: Load → Split → Embed → Store in OracleVS
• Retrieval: Hybrid search combining semantic similarity and keyword search
• Intelligence Layer: Semantic cache + persistent chat history
• Answer Generation: Use retrieved context to generate responses

Step 1: Document Ingestion Pipeline

We’ll read runbook content from a database table, split it intelligently, and store the chunks with embeddings.

from langchain_oracledb.document_loaders import OracleDocLoader, OracleTextSplitter
from langchain_oracledb.vectorstores import OracleVS, DistanceStrategy
from langchain_community.embeddings import HuggingFaceEmbeddings

def ingest_documents(conn):
    # Load documents with metadata
    loader = OracleDocLoader(
        conn=conn,
        params={
            "owner": conn.username,
            "tablename": "RUNBOOK_SOURCE",
            "colname": "CONTENT",
            "mdata_cols": ["ID", "TITLE", "CATEGORY"]
        }
    )
    docs = loader.load()

    # Create vector store
    embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2")
    
    vs = OracleVS(
        conn,
        embeddings,
        table_name="DOCUMENT_VECTORS",
        distance_strategy=DistanceStrategy.COSINE
    )

    # Split and store
    splitter = OracleTextSplitter(
        conn=conn,
        params={"by": "words", "max": 250, "split": "sentence"}
    )

    vs.add_documents(docs, text_splitter=splitter)
    return vs

Step 2: Hybrid Retrieval

Combine semantic search (vector similarity) with keyword search for better results.

from langchain_oracledb.retrievers import OracleTextSearchRetriever

def hybrid_retrieve(vector_store, query, k=5):
    # Semantic search
    semantic_docs = vector_store.similarity_search(query, k=k)
    
    # Keyword search
    keyword_retriever = OracleTextSearchRetriever(
        vector_store=vector_store,
        k=k
    )
    keyword_docs = keyword_retriever.invoke(query)
    
    # Simple fusion logic (you can improve this with RRF)
    combined = semantic_docs + keyword_docs
    # Deduplicate and rank (basic version shown)
    seen = set()
    unique_docs = []
    for doc in combined:
        doc_id = doc.metadata.get("ID")
        if doc_id not in seen:
            seen.add(doc_id)
            unique_docs.append(doc)
    
    return unique_docs[:k]

Step 3: Add Semantic Caching

Reuse answers for similar questions to reduce cost and latency.

from langchain_oracledb.cache import OracleSemanticCache
from langchain.schema import Generation

def get_cached_or_generate(conn, embeddings, query, context):
    cache = OracleSemanticCache(
        conn,
        embeddings,
        table_name="SEMANTIC_CACHE",
        score_threshold=0.85
    )
    
    cached = cache.lookup(query, "answer_cache")
    
    if cached:
        return cached[0].text, True  # cache hit
    
    # Generate new answer (call your LLM here)
    answer = generate_response(query, context)
    
    cache.update(query, "answer_cache", [Generation(text=answer)])
    return answer, False

Step 4: Persist Conversation History

Keep full chat context across sessions.

from langchain_oracledb.chat_message_histories import OracleChatMessageHistory
from langchain.schema import HumanMessage, AIMessage

def save_to_history(conn, session_id, question, answer):
    history = OracleChatMessageHistory(
        session_id,
        client=conn,
        table_name="CONVERSATION_HISTORY"
    )
    
    history.add_messages([
        HumanMessage(content=question),
        AIMessage(content=answer)
    ])
    
    return len(history.messages)

Complete End-to-End Function

Here’s how everything works together in a single function:

def ask_question(conn, vector_store, question, session_id="default"):
    embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2")
    
    # 1. Hybrid retrieval
    relevant_docs = hybrid_retrieve(vector_store, question)
    context = "\n\n".join([doc.page_content for doc in relevant_docs])
    
    # 2. Check cache or generate
    answer, was_cached = get_cached_or_generate(conn, embeddings, question, context)
    
    # 3. Save to history
    history_length = save_to_history(conn, session_id, question, answer)
    
    return {
        "answer": answer,
        "cached": was_cached,
        "sources": len(relevant_docs),
        "history_messages": history_length
    }

How to Run This Locally

1. Install dependencies with Poetry
2. Run the sample script — it automatically spins up an Oracle AI Database Free container using Testcontainers
3. Ask questions and observe hybrid retrieval, caching behavior, and growing chat history

Benefits of This Approach

• Single database for vectors, documents, cache, and history
• Hybrid search improves answer quality
• Semantic caching reduces expensive LLM calls
• Conversation state is durable and queryable
• Very little custom code required thanks to langchain-oracledb

Final Thoughts

Building a solid RAG system doesn’t have to be complex. By leveraging Oracle AI Database through the official LangChain integration, you get a clean, maintainable pipeline that handles ingestion, retrieval, caching, and memory in one place.

This pattern scales well and keeps your architecture simple while delivering strong retrieval performance.

Start experimenting with the sample, you’ll be surprised how quickly you can get a capable system running.

 If you have been wiring local AI agents to MCP servers, you already know the uneasy feeling. You connect a model, give it some tools, send it off on a task, and then you just hope it behaves. You have no real view into what it is calling, and no easy way to stop it when it does something it should not.

I spent some hands-on time with Archestra, an open source AI platform that fixes exactly this, and ran the whole thing locally on my own hardware.

What Archestra Is

Archestra is an all-in-one, open source platform for running AI agents safely. It pulls together the pieces you would normally wire up yourself: a chat interface, a no-code agent builder, an LLM gateway, an MCP gateway, a private MCP registry, deterministic guardrails, and full observability. One Docker command brings the whole stack up. The team behind it previously worked on Grafana OnCall, so the production thinking shows.

Running It Locally

I drove everything with a local model, Qwen3.6 27B served through Ollama, on my own GPU. No cloud dependency for inference. Archestra is provider agnostic, so pointing it at a local Ollama endpoint took a single configuration step.

The Part That Matters

I built a simple agent and gave it one tool: a website reader pulled from Archestra's MCP registry. What stood out is that every MCP server runs as its own isolated pod inside a Kubernetes cluster that Archestra spins up automatically. That is real isolation, not just a local process.

I ran a task and watched the agent make its tool call live. Every step it took was visible. Then came the payoff. I set a deterministic guardrail to block that tool, re-ran the task, and the agent could no longer touch it. The block is enforced at the platform level, so a prompt cannot talk its way around it.

That is the whole point. Seeing what your agents do is good. Being able to stop them, deterministically, is what makes agentic AI safe to run.

Try It Yourself

Archestra is open source and self-hostable. Grab it from GitHub, run the Docker quickstart, and try the same flow on your own machine.

Watch the full hands-on walkthrough in the video below.

https://youtu.be/9JiA6RYpEYo

Understanding how Linux handles network packets at the kernel level can feel overwhelming — until you see how the pieces fit together. Netfilter provides the foundation, while nftables gives us a modern, flexible way to define firewall rules, NAT, and packet mangling.

Whether you’re debugging connectivity issues, writing security tools, or optimizing performance, knowing these internals helps you work more effectively with Linux networking.

Netfilter: The Kernel’s Packet Processing Framework

Netfilter is the Linux kernel’s packet filtering and mangling infrastructure. It defines well-known hook points where packets can be inspected and modified as they flow through the system:

• PREROUTING — Right after a packet arrives, before routing decisions
• INPUT — Packets destined for the local system
• FORWARD — Packets being routed through the host
• OUTPUT — Locally generated packets
• POSTROUTING — After routing, before leaving the host

Chains attached to these hooks let you enforce security policies, perform NAT, or influence routing.

nftables: The Modern Replacement for iptables

nftables brings a cleaner, more consistent syntax and better performance compared to the older iptables framework. It organizes configuration into tables, chains, rules, sets, and expressions.

Core nftables Building Blocks Tables

Containers that group related chains, sets, and rules. Common families include ip (IPv4), ip6 (IPv6), and inet (both).

nft add table ip myfirewall

Chains

Sequences of rules. Base chains attach directly to Netfilter hooks and define behavior (filter, nat, route).

nft add chain ip myfirewall input { type filter hook input priority 0 \; }

Rules

Define matching conditions and actions (accept, drop, jump, etc.).

nft add rule ip myfirewall input tcp dport 22 accept

Sets

Efficient collections for matching (IP addresses, ports, etc.).

nft add set ip myfirewall trusted_ips { type ipv4_addr \; }
nft add element ip myfirewall trusted_ips { 192.168.1.10, 10.0.0.5 }

Practical Example: Simple Firewall

Here’s how to create a basic firewall that allows SSH from trusted IPs and drops everything else:

nft add table ip myfirewall
nft add chain ip myfirewall input { type filter hook input priority 0 \; }
nft add set ip myfirewall trusted_ips { type ipv4_addr \; }
nft add element ip myfirewall trusted_ips { 192.168.1.1, 192.168.1.2 }
nft add rule ip myfirewall input ip saddr @trusted_ips accept
nft add rule ip myfirewall input drop

Behind the Scenes: User Space to Kernel

Tools like nft use libmnl and libnftnl to communicate with the kernel via Netlink. This allows atomic batch operations — multiple changes applied together or not at all — ensuring consistent firewall state.

Best Practices for Production

• Use named sets for frequently updated lists (trusted IPs, blocked addresses)
• Keep base chains simple and explicit with a final drop rule
• Leverage priorities to control execution order
• Batch operations when making multiple changes
• Monitor and log dropped packets for visibility

Conclusion

Netfilter and nftables form a powerful, unified framework for packet processing in Linux. Understanding how tables, chains, rules, and sets work together helps you build more effective firewalls, troubleshoot network issues faster, and appreciate the elegance of the modern Linux networking stack.

Whether you’re securing servers, implementing complex NAT rules, or exploring kernel internals, nftables gives you the tools to control traffic with precision and clarity.

Most Oracle DBAs and developers copy-paste the same “recommended” TNS connection string for RAC and Data Guard without fully understanding how each parameter affects real-world behavior. That changes today.

This guide breaks down the critical parameters in a typical HA connect descriptor, shows measurable timing impacts, and gives clear guidance on when to tune what — so your applications stay resilient during switchovers, failovers, and maintenance.

The Standard HA Connect String

Here’s the common pattern you’ll see in MAA documentation:

(DESCRIPTION =
  (CONNECT_TIMEOUT=90)(RETRY_COUNT=100)(RETRY_DELAY=3)
  (TRANSPORT_CONNECT_TIMEOUT=1000ms)
  (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = ...))
  (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = ...))
  (CONNECT_DATA = (SERVICE_NAME = my_service))
)

Let’s explore what each setting actually does and how changing it impacts connection behavior.

1. FAILOVER = ON (Default)

Controls whether the client tries alternate addresses when one fails. Keep this ON unless you have a very specific reason to disable it. Turning it OFF makes connections order-dependent and can prevent reaching an available site during role transitions.

2. LOAD_BALANCE = ON

Randomizes the starting address in an ADDRESS_LIST. This prevents one SCAN IP from being hammered and helps spread load. Strongly recommended when you have multiple addresses, especially during partial outages or maintenance.

3. RETRY_COUNT & RETRY_DELAY

RETRY_COUNT defines how many additional rounds the client makes through the address list. RETRY_DELAY adds a pause between rounds so the service has time to become available after a switchover or failover.

Tip: Use RETRY_DELAY=3 (seconds) as a good starting point. Tight loops (RETRY_DELAY=0) create unnecessary load and should be avoided in production.

4. TRANSPORT_CONNECT_TIMEOUT

This is crucial when an IP or port is unreachable. It caps how long the client waits for a TCP connect before moving to the next address. Set it low enough to fail fast during outages, but high enough to handle normal network jitter (1000ms is a common balanced value).

5. CONNECT_TIMEOUT

Limits the total time for a single connection attempt, including server process creation. Set this higher than TRANSPORT_CONNECT_TIMEOUT (commonly 60–90 seconds) to allow normal connects under load while protecting against hanging attempts.

Practical Recommendations

• For frequent role changes (Fast-Start Failover): Use LOAD_BALANCE=on and moderate RETRY_COUNT
• For stable primary with rare switchovers: Prefer LOAD_BALANCE=off with clear site ordering
• Always set TRANSPORT_CONNECT_TIMEOUT explicitly — don’t rely on defaults
• Align your application connection pool timeouts with the worst-case client wait time
• Use the latest Oracle client (26ai recommended) for millisecond precision support

Final Advice

Don’t treat the HA connection string as magic copy-paste code. Understand what each parameter controls and tune it to your environment’s failover patterns and network characteristics. Small changes here can dramatically improve application resilience during planned maintenance and unplanned outages.

Test your connection strings under simulated failure scenarios (service down, network blocked) and measure real connect times. The better you understand your client behavior, the more predictable and reliable your high-availability applications will be.

Mission-critical applications demand minimal downtime and lightning-fast recovery. With Oracle AI Database 26ai, Oracle has dramatically improved Data Guard and Active Data Guard role transitions, making high-availability architectures faster and more reliable than ever.

These enhancements push Oracle Maximum Availability Architecture (MAA) Platinum tier capabilities across Oracle’s multicloud ecosystem, giving organizations consistent, enterprise-grade resilience no matter where they run.

Game-Changing Performance Improvements

Oracle’s testing shows impressive gains:

• Up to **5x faster failovers** — often completing in under 30 seconds
• Up to **3.4x faster switchovers**
• Consistent results across both small and large workloads
• No changes required to your applications

These optimizations span database recovery, checkpoint processing, service management, and multitenant operations — delivering real reductions in Recovery Time Objectives (RTO).

MAA Platinum Tier Now Available Across Multicloud

Organizations using Oracle Database@Azure, Oracle Database@AWS, or Oracle Database@Google Cloud can now standardize on the same Platinum MAA architecture:

• Local HA with RTO under 10 seconds
• Regional DR with RTO under 30 seconds
• Zero or near-zero Recovery Point Objective (RPO)

This consistency lets teams apply the same proven best practices, operational procedures, and resiliency strategies across all their multicloud deployments.

Why This Matters for Your Business

• Less Downtime — Faster planned maintenance and unplanned recovery
• Better User Experience — Minimal disruption during role transitions
• Simplified Operations — Standardize high-availability practices across environments
• Future-Proof Architecture — Built for the most demanding mission-critical workloads

Who Should Upgrade?

Existing Exadata and Exadata Database Service customers running Active Data Guard will see immediate benefits from moving to Oracle AI Database 26ai. The performance gains make Platinum MAA tier objectives much more achievable without major architectural overhauls.

Next Steps

If you’re running mission-critical databases, now is the perfect time to evaluate Oracle AI Database 26ai. The combination of Exadata performance, Active Data Guard, and these accelerated role transitions creates one of the strongest availability platforms available today.

Explore the updated MAA reference architectures and multicloud certification matrix to see how you can strengthen your high-availability strategy across Oracle Cloud and major hyperscalers.

One of the nicest things about OKafka is how familiar it feels if you’ve used Kafka before. You configure connections with Properties objects, just like kafka-clients. The big difference? You’re talking directly to Oracle Database Transactional Event Queues instead of a separate broker.

Here’s how to set up authentication cleanly for development and production.

Two Main Authentication Paths 1. PLAINTEXT (Great for Local Dev)

Simple username/password setup using an ojdbc.properties file:

Properties props = new Properties();
props.put("security.protocol", "PLAINTEXT");
props.put("bootstrap.servers", "your-host:port");
props.put("oracle.service.name", "your_service_name");
props.put("oracle.net.tns_admin", "/path/to/config/dir");

Your ojdbc.properties file should contain:

user=testuser
password=YourStrongPassword123

2. SSL / mTLS (Production Ready)

Use Oracle Wallet for secure connections. Point to your wallet directory and specify the TNS alias:

props.put("security.protocol", "SSL");
props.put("oracle.net.tns_admin", "/path/to/wallet");
props.put("tns.alias", "your_tns_alias");

Full Working Example

Here’s a complete snippet to create an AdminClient and make a topic:

try (Admin admin = AdminClient.create(props)) {
    NewTopic topic = new NewTopic("MY_EVENTS", 5, (short) 0);
    admin.createTopics(Collections.singletonList(topic)).all().get();
    System.out.println("Topic created successfully");
}

Pro Tips for Smooth Sailing

• Always use uppercase topic names with OKafka
• Store wallet files securely and never commit them to version control
• Test with Oracle Database Free + Testcontainers for quick iterations
• Move to mTLS early in your development cycle

Final Thoughts

OKafka makes connecting to Oracle feel just like connecting to any other Kafka cluster — but you get all the power, security, and transactional guarantees of the database built right in.

No extra infrastructure. No separate cluster to manage. Just reliable event streaming where your data already lives.

Want the familiar Kafka Java APIs without standing up and managing a separate Kafka cluster? Oracle’s **OKafka** (Kafka Java Client for Transactional Event Queues) lets you produce and consume events straight from your Oracle Database — with full transactional guarantees and exactly-once semantics.

Here’s everything you need to know to get started quickly and build reliable event-driven applications on Oracle AI Database.

Why OKafka?

• Use standard Kafka Java producer/consumer code
• Events are stored and processed inside the database
• Atomic transactions between database changes and event publishing
• No separate message broker to operate and scale
• Works with Oracle Database 23ai Free and above

Quick Start: Database Setup

First, create a database user with the required privileges:

CREATE USER okafka_user IDENTIFIED BY Oracle123;

GRANT AQ_USER_ROLE TO okafka_user;
GRANT CONNECT, RESOURCE, UNLIMITED TABLESPACE TO okafka_user;
GRANT EXECUTE ON DBMS_AQ TO okafka_user;
GRANT EXECUTE ON DBMS_AQADM TO okafka_user;
GRANT SELECT ON GV_$SESSION TO okafka_user;
-- ... (full list in documentation)

Then create your first topic:

BEGIN
    DBMS_AQADM.CREATE_DATABASE_KAFKA_TOPIC(
        topicname => 'MY_TOPIC',
        partition_num => 5,
        retentiontime => 7*24*3600
    );
END;

Connection Configuration Option 1: PLAINTEXT (Simple)

security.protocol=PLAINTEXT
bootstrap.servers=your-host:port
oracle.service.name=your_service
oracle.net.tns_admin=/path/to/ojdbc.properties

Option 2: SSL (Recommended for Production)

Use Oracle Wallet for secure mTLS connections.

Building Your First OKafka App

1. Clone the OKafka distribution
2. Build with Gradle: ./gradlew jar or ./gradlew fullJar
3. Add the resulting JAR to your project

Producer Example

Properties props = new Properties();
props.put("bootstrap.servers", "your-host:port");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

KafkaProducer producer = new KafkaProducer<>(props);

ProducerRecord record = new ProducerRecord<>("MY_TOPIC", "key1", "Hello from OKafka!");
producer.send(record).get();

producer.close();

Consumer Example

KafkaConsumer consumer = new KafkaConsumer<>(props);
consumer.subscribe(Collections.singletonList("MY_TOPIC"));

while (true) {
    ConsumerRecords records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord record : records) {
        System.out.println("Received: " + record.value());
    }
}

Best Practices

• Use transactions for atomic database + event operations
• Always handle proper error paths and rollbacks
• Test with Testcontainers + Oracle Database Free
• Monitor queue depth and consumer lag
• Start with PLAINTEXT for development, move to SSL in production

Conclusion

OKafka brings the power and familiarity of Kafka directly into Oracle Database. You get enterprise-grade messaging with transactional integrity, high availability, and zero additional infrastructure to manage.

Whether you’re building microservices, event-driven architectures, or real-time analytics, OKafka lets you leverage your existing Oracle investment for reliable pub/sub messaging.

Building event-driven applications usually means standing up another system — Kafka, RabbitMQ, or similar. But what if your database could handle reliable messaging natively, with full transactional guarantees and zero extra infrastructure?

That’s exactly what **Oracle Database Transactional Event Queues (TxEventQ)** delivers.

What Is TxEventQ?

TxEventQ is a built-in, high-performance messaging system inside Oracle Database. It supports:

• Multiple producers and consumers
• Exactly-once delivery semantics
• Partitioned queues with ordering guarantees
• Full SQL access to events and metadata

Available since Oracle Database 21c (including the free edition), it’s ready to use today.

Why Teams Are Choosing TxEventQ

• Simplified Architecture — No separate message broker to manage, patch, or scale
• Transactional Integrity — Database changes and message publishing happen atomically
• Exactly-Once Semantics — Critical for financial, compliance, and mission-critical flows
• SQL-Native — Query, join, and analyze events using familiar SQL

It’s especially powerful when you need tight coupling between data changes and event publishing — no dual-write problems.

How to Get Started

The easiest path for Java developers is the **Kafka Java Client for Oracle TxEventQ (OKafka)**. It uses the familiar Kafka APIs you already know, but talks directly to the database.

Other options include:

• PL/SQL using DBMS_AQ
• REST via Oracle REST Data Services (ORDS)
• Python, Node.js, .NET, and other language drivers

Real-World Use Cases

• Event-driven microservices inside the database
• Change Data Capture (CDC) patterns
• Application integration and workflow orchestration
• Real-time analytics and notifications

Pro Tips from the Field

• Start with the Kafka Java API if you’re already familiar with Kafka
• Use triggers for automatic event publishing on DML operations
• Leverage partitioning for high-throughput scenarios
• Combine with Oracle AI Database features for intelligent event processing

Conclusion

TxEventQ lets you bring reliable pub/sub messaging directly into your Oracle Database, eliminating the need for yet another system to manage. It’s fast, transactional, and deeply integrated with everything else Oracle Database offers.

Whether you’re modernizing legacy systems, building new event-driven apps, or simplifying your architecture, TxEventQ is worth serious consideration.

 

Writing solid Kafka Java code for Oracle AI Database’s Transactional Event Queues (using OKafka) can be tricky. Agents often miss Oracle-specific patterns around authentication, transactions, serialization, and testing.

That’s why I created a focused agent skill: **okafka-java-code** — designed to generate high-quality, production-ready OKafka applications from the start.

Why This Skill Exists

Most AI coding assistants generate OKafka code that works... but not well. They miss key Oracle behaviors like using `getDBConnection()` for transactional consistency, proper topic administration, and realistic testing with Testcontainers.

This skill packages the hard-won patterns I use daily into something any agent can reuse.

What the Skill Includes

• OKafka administration (topic creation)
• Authentication and connection properties
• Transactional producer and consumer patterns
• OSON serialization best practices
• Integration testing with Testcontainers
• Troubleshooting and common pitfalls

See It in Action

Here’s the kind of clean, correct code the skill generates for a transactional workflow:

private void publish(BusinessEvent event, boolean failAfterDatabaseWrite) throws Exception {
    producer.beginTransaction();
    try {
        producer.send(new ProducerRecord<>(topic, event.id(), event.payload())).get();
        insertProducedEvent(producer.getDBConnection(), event);
        
        if (failAfterDatabaseWrite) {
            throw new IllegalStateException("Simulated failure");
        }
        
        producer.commitTransaction();
    } catch (Exception e) {
        abortAndRethrow(e);
    }
}

And the consumer side follows the same safe transactional pattern.

The Testing Story

The skill also generates full integration tests using Testcontainers + Oracle Database Free. It validates:

• Successful commit (data + Kafka record both visible)
• Producer abort (no data persisted)
• Consumer rollback (message available for retry)

How to Use It

1. Install the skill from the GitHub repo
2. Describe your use case to your agent
3. Review and run the generated code
4. Iterate with confidence

Final Thoughts

Good agent skills shift the conversation. Instead of fixing basic setup issues, you can focus on business logic, transaction correctness, and real application behavior.

By packaging proven OKafka patterns into a reusable skill, you raise the baseline quality of every generated application — saving hours of debugging and review time.

If you work with Oracle AI Database and Kafka-style messaging, give this skill a try. It’s one of the fastest ways to go from “it compiles” to “this is production-ready.”

Need lightning-fast, in-memory caching for your modern applications? Oracle Cloud Infrastructure (OCI) Cache delivers a fully managed Valkey and Redis-compatible service that removes the operational burden of running your own cache clusters.

Whether you're accelerating database queries, powering session stores, or supporting real-time features, OCI Cache gives you enterprise-grade performance with zero infrastructure management.

Why Choose OCI Cache?

• Fully managed — Oracle handles patching, scaling, monitoring, and high availability
• Compatible with Valkey 8.1 (recommended), Valkey 7.2, and Redis 7.0
• Supports both non-sharded and sharded cluster architectures
• Easy resizing of nodes, shards, and memory allocation
• Built-in monitoring, alarms, and automatic security updates

Cluster Types Explained Non-Sharded Clusters

Ideal for most general-purpose caching needs. Scale from 1 to 5 nodes (1 primary + up to 4 replicas) with automatic distribution across fault and availability domains for high availability.

Sharded Clusters

Designed for massive scale. Split your data across 3 to 99 shards, each with its own primary and up to 4 replicas. Perfect for large datasets and high-throughput workloads.

Key Capabilities

• Resizing — Dynamically adjust node count, shard count, or memory per node
• Automatic Patching — OCI handles security updates and engine upgrades with minimal disruption
• Monitoring & Alarms — Built-in metrics for health, capacity, and performance
• High Availability — Replica nodes and intelligent placement for resilience

Getting Started with OCI Cache

1. Navigate to OCI Cache in the Console
2. Create a new cluster and choose your engine version
3. Select non-sharded or sharded topology
4. Configure memory size and node count
5. Connect your applications using standard Valkey/Redis clients

Best Practices

• Start with Valkey 8.1 for the latest features and performance
• Use sharded clusters when your dataset or throughput exceeds single-node limits
• Monitor key metrics like cache hit ratio, evictions, and CPU utilization
• Plan for resizing early — horizontal and vertical scaling are both supported
• Leverage replicas for read-heavy workloads and high availability

Conclusion

OCI Cache takes the complexity out of running high-performance caching infrastructure. With managed Valkey and Redis clusters, automatic scaling, and deep integration with the rest of OCI, you can focus on building great applications instead of managing cache servers.

Whether you're accelerating APIs, reducing database load, or powering real-time features, OCI Cache delivers the speed and reliability your applications need — without the operational overhead.

Ready to add blazing-fast caching to your OCI workloads? Create your first OCI Cache cluster today in the Oracle Cloud Console.

OCI Cache | Valkey | Redis | Managed Caching | Oracle Cloud Infrastructure

Tags: