Oracle Advanced Queuing (AQ): Messages, Transactions and Consumers

The acronym AQ in Oracle stands for Advanced Queuing. Oracle Advanced Queues provide a database-integrated messaging system that allows applications to exchange information asynchronously using database tables as the transport layer. Because AQ is built into the Oracle Database engine, it inherits core database capabilities such as transactional consistency, security, backup and recovery, and high availability.

In this lesson, you will learn what Advanced Queues are, how Oracle stores messages in queue tables, and why AQ remains a relevant option in Oracle 26ai and cloud-enabled deployments. Later lessons in this module will show how to enqueue and dequeue messages, build PL/SQL applications, and configure queue propagation. This page focuses on the concepts and architecture.

Learning objectives

• Understand the role of Advanced Queues as a messaging platform inside the Oracle Database.
• Distinguish between messages, queues, and queue tables.
• Identify common use cases where AQ improves performance and reliability.
• Recognize how AQ fits into Oracle 26ai and cloud-enabled architectures.
• See how this overview page relates to more detailed AQ lessons in the module.

Why use messaging inside the database?

Many applications need to perform work asynchronously. For example, an order-entry system may take a customer’s order immediately, then process payment, inventory checks, and shipment in the background. Rather than forcing all systems to be online and synchronized at once, a messaging system decouples producers and consumers of work.

Oracle Advanced Queues implement this messaging layer inside the database. Instead of running a separate message broker, AQ uses Oracle tables to store messages and Oracle background processes to manage delivery. This has several benefits:

• Transactional consistency – messages can be enqueued and database changes committed in a single transaction.
• Unified security model – database users, roles, and privileges control who can enqueue, dequeue, or manage queues.
• Operational simplicity – fewer moving parts to install, patch, and monitor.
• Integration with existing tools – AQ can be monitored and managed using data dictionary views, PL/SQL packages, and Oracle Enterprise tooling.

Core AQ building blocks: messages, queues, and queue tables

At the logical level, Advanced Queuing revolves around three core concepts:

• Message – a single unit of data describing an event or work item, such as a “New Order” notification or “Invoice Generated” event.
• Queue – a named logical container that holds messages awaiting processing. Producers enqueue messages into a queue; consumers dequeue them.
• Queue table – a physical Oracle table used to store the messages for one or more queues. Queue tables are created and managed through AQ administration packages, not by ordinary DDL alone.

The figure summarizes the producer-to-queue-to-consumer flow:

Queue tables: how messages are stored

A queue table is a specially created Oracle table that holds messages for one or more queues. You do not manually design its columns; instead, you specify message characteristics and storage options, and Oracle builds the underlying structure for you. The queue table:

• Stores message metadata (ID, enqueue time, expiration, priority, state).
• Stores the payload type supported and configured for the chosen queue technology and API; classic AQ and TxEventQ capabilities are not identical.
• Supports transactional operations so that enqueue/dequeue can be committed or rolled back with other SQL changes.
• Uses indexes and internal structures optimized for message lookup and ordering.

Use DBMS_AQADM for administration and supported messaging interfaces such as DBMS_AQ for enqueue/dequeue. Do not manually update message rows or add arbitrary indexes and partitions to Oracle-managed queue structures. Queue storage is an implementation detail with documented administration rules.

Example: commit an order and its message together

Suppose an application inserts order 801 and must request warehouse processing. With persistent enqueue visibility set to ON_COMMIT, it can insert the order and enqueue the work item in the same transaction. A commit makes both durable; a rollback abandons both. This avoids committing the order and then losing the request before an unrelated messaging call succeeds.

1. The producer inserts order 801 and enqueues an OrderCreated message carrying its identifier.
2. The producer commits. A consumer can now process the message.
3. The consumer dequeues in a transaction, updates database fulfillment state, and commits.
4. If that consumer transaction rolls back, its database changes are undone and the message can become available for another attempt under the queue's retry policy.

This is a transaction walkthrough, not a complete installation script. Immediate visibility and buffered messaging have different semantics. Choose the options deliberately rather than assuming every enqueue shares the caller's transaction.

External effects need separate protection. Sending an email or calling a payment API does not automatically roll back with the database. Use a stable event identifier and an idempotent consumer or external API so retrying work does not charge a customer twice. Database messaging guarantees do not eliminate this application responsibility.

Queues and consumers

A queue is defined on top of a queue table. Each queue has its own:

• Name and schema ownership.
• Configuration options (e.g., single-consumer vs. multi-consumer).
• Association with one or more subscribers or consumers.
• Policies (retention, ordering rules, and visibility options).

Consumers can be PL/SQL blocks, background jobs, middle-tier services, or external applications using database connectivity. Consumers in Oracle 26ai deployments might be:

• Microservices connecting through Oracle Net and processing messages as part of an event-driven workflow.
• Batch jobs that periodically dequeue work for offline processing.
• Integration components that transform AQ messages into other messaging systems or APIs.

Classic AQ and Transactional Event Queues

Oracle 26ai provides classic AQ and Transactional Event Queues (TxEventQ), an optimized implementation previously called sharded queues. Both integrate messaging with the database, but the selection should follow workload and API requirements.

For an existing AQ application, begin with its payload type, subscriber model, queue administration, and operational procedures. For a new high-throughput event workload, evaluate TxEventQ's supported interfaces and ordering model. Do not treat a change of queue technology as merely renaming an object.

A single-consumer queue can distribute work among competing workers. A multiconsumer queue tracks delivery for its intended recipients. Neither arrangement means that arbitrary parallel consumers finish messages in one global order. If updates for one customer must be applied sequentially, make that ordering requirement part of the design and test it under concurrency.

When to use Advanced Queues

Advanced Queues are particularly useful when you need:

• Asynchronous processing – work can be queued and processed later, decoupling user interactions from back-end tasks.
• Persistent work records – committed persistent messages participate in database durability and recovery; expiration, retries, and exception handling still need policies.
• Explicit ordering requirements – select queue and consumer options that meet the required order, rather than assuming global FIFO completion.
• Tight coupling to database state – the success of a business transaction and the creation of a message should be atomic.

If your architecture already depends heavily on the Oracle Database, AQ can be simpler and more maintainable than running a separate message broker—especially for small to medium integration workloads that benefit from transactional guarantees and centralized administration.

Performance and reliability considerations

Because AQ runs inside the database, performance and reliability are closely tied to standard Oracle tuning practices:

• Persistent versus buffered – persistent messaging uses database durability mechanisms; buffered messaging does not provide the same crash-recovery guarantees.
• Backlog and latency – monitor message age, ready-message growth, dequeue throughput, and consumer failures before changing storage settings.
• Concurrency – multiple producers and consumers can operate concurrently, and dequeue options can control visibility and locking behavior.
• Recovery and retries – test persistent-message recovery and exception-queue handling, and verify that replay does not duplicate external effects.

Later lessons in this module will show how enqueue and dequeue options affect concurrency, how to configure retention and message expiration, and how to tune queue tables for performance.

How this page fits into the Advanced Queues module

This page is the conceptual foundation for the Advanced Queues lessons. Use it as your reference for what AQ is and how its core components fit together. The following pages build on this material:

• How to Enqueue and Dequeue Messages in Oracle AQ (PL/SQL Tutorial)
  Focus: practical enqueue/dequeue examples and processing patterns in PL/SQL.
• PL/SQL Tutorial: Building a Complete Oracle AQ Application
  Focus: end-to-end example that creates queue tables, queues, and application logic.
• Oracle Queue Propagation: Distributed Messaging and Propagation Paths
  Focus: moving messages between queues and databases, including cloud-enabled scenarios.
• Conclusion: Key Takeaways from Oracle Advanced Queues (AQ)
  Focus: summary, best practices, and when to choose AQ in real-world designs.

Once you are comfortable with the ideas presented here—message, queue, queue table, and the overall AQ architecture—you will be ready to explore the implementation details in the remaining lessons of this module.

Reference: Oracle introduction to TxEventQ and Advanced Queuing.