Oracle AQ是数据库内建队列，无独立协议或SDK，C#必须通过OracleCommand执行DBMS_AQ/DBMS_AQADM的PL/SQL调用，依赖预建队列表、严格匹配消息类型、显式事务控制及异常处理，无法像RabbitMQ那样直连收发。
OracleAQ 不是 .NET 原生支持的队列机制，C# 无法直接通过 Oracle.ManagedDataAccess 调用 AQ 的 PL/SQL 接口完成完整收发——必须借助 Oracle 提供的 DBMS_AQ 和 DBMS_AQADM 包，用纯 SQL/PLSQL 操作，再由 C# 执行这些语句。
为什么不能像 RabbitMQ 那样用客户端库直连收发
Oracle AQ 是数据库内建的队列服务，没有独立的网络协议或客户端 SDK。所有操作（入队、出队、监听）最终都转化为对 QUEUES、QUEUE_TABLES 等数据字典的 DML 或对 DBMS_AQ.ENQUEUE/DBMS_AQ.DEQUEUE 的 PL/SQL 调用。C# 只能通过 OracleCommand 执行这些语句，且必须处理：
- 事务边界：入队/出队默认参与当前事务，需显式
Commit才真正生效 - 消息类型限制：只支持 Oracle 内置类型（如
SYS.AQ$_JMS_TEXT_MESSAGE）或自定义 OBJECT 类型，不支持任意 .NET 对象序列化 - 出队阻塞逻辑：纯 SQL 无法实现“等待 5 秒直到有消息”，得靠
WAIT => 5参数 +DBMS_AQ.DEQUEUE的 PL/SQL 调用
创建队列前必须手动建 QUEUE_TABLE 和 QUEUE
不能靠 C# 代码自动初始化，必须提前在数据库中运行 PL/SQL 创建基础结构。常见错误是跳过这步，直接调用 ENQUEUE 导致 ORA-24010: QUEUE does not exist：
BEGIN
DBMS_AQADM.CREATE_QUEUE_TABLE(
queue_table => 'my_queue_table',
queue_payload_type => 'SYS.AQ$_JMS_TEXT_MESSAGE'
);
DBMS_AQADM.CREATE_QUEUE(
queue_name => 'my_queue',
queue_table => 'my_queue_table'
);
DBMS_AQADM.START_QUEUE(queue_name => 'my_queue');
END;注意：
-
queue_payload_type必须与后续入队消息类型严格一致；若要用自定义类型，得先CREATE TYPE -
START_QUEUE必须执行，否则DEQUEUE会报ORA-25228: timeout or end-of-fetch during message dequeue - C# 中无需重复执行这些，但部署脚本里必须包含
入队（ENQUEUE）要构造合法的 AQ$_JMS_TEXT_MESSAGE 对象
不能直接传字符串，必须用 Oracle 的 JMS 兼容消息格式。最简方式是用 DBMS_AQ.ENQUEUE 的 PL/SQL 块，让 Oracle 自动构造：
DECLARE
l_enqueue_options DBMS_AQ.ENQUEUE_OPTIONS_T;
l_message_properties DBMS_AQ.MESSAGE_PROPERTIES_T;
l_message_handle RAW(16);
l_message SYS.AQ$_JMS_TEXT_MESSAGE;
BEGIN
l_message := SYS.AQ$_JMS_TEXT_MESSAGE.CONSTRUCT();
l_message.set_text('Hello from C#');
<p>DBMS_AQ.ENQUEUE(
queue_name => 'my_queue',
enqueue_options => l_enqueue_options,
message_properties => l_message_properties,
payload => l_message,
msgid => l_message_handle
);
END;关键点：
- payload 类型必须是
SYS.AQ$_JMS_TEXT_MESSAGE，不能是VARCHAR2或CLOB - 如果改用自定义 OBJECT 类型，C# 中就得用
OracleObject映射，复杂度陡增 - 不要在 C# 里拼接 PL/SQL 字符串传参——容易被注入，应使用绑定参数（如
command.Parameters.Add("p_text", OracleDbType.Varchar2).Value = "Hello"），并在 PL/SQL 块里赋值
出队（DEQUEUE）必须用匿名块并处理 NO_MESSAGE 异常
单纯 SELECT 无效，必须调用 DBMS_AQ.DEQUEUE。典型错误是忽略 NO_DATA_FOUND（即无消息时抛 ORA-01403），导致程序中断：
DECLARE l_dequeue_options DBMS_AQ.DEQUEUE_OPTIONS_T; l_message_properties DBMS_AQ.MESSAGE_PROPERTIES_T; l_message_handle RAW(16); l_message SYS.AQ$_JMS_TEXT_MESSAGE; l_text VARCHAR2(4000); BEGIN l_dequeue_options.wait := 5; -- 等待 5 秒 <p>DBMS_AQ.DEQUEUE( queue_name => 'my_queue', dequeue_options => l_dequeue_options, message_properties => l_message_properties, payload => l_message, msgid => l_message_handle );</p><p>l_text := l_message.get_text(); :out_text := l_text; -- 绑定输出参数给 C# EXCEPTION WHEN NO_DATA_FOUND THEN :out_text := NULL; -- 显式返回 null，C# 判断是否为空 END;
对应 C# 代码中需：
- 声明输出参数：
command.Parameters.Add("out_text", OracleDbType.Varchar2, ParameterDirection.Output) - 检查
parameter.Value == DBNull.Value来判断是否超时无消息 - 避免把
wait => 0当“非阻塞”用——它仍会立即返回，但可能因锁竞争失败，不如设为 1 秒更稳
真正的难点不在语法，而在于事务耦合和异常路径覆盖：入队后未 Commit，整个事务回滚会导致消息消失；出队后未 Commit，消息会重新入队（默认 visibility => IMMEDIATE）。这些细节一旦漏掉，队列行为就不可预测。
