oracle pl/sql 无原生事件驱动编程能力，唯一原生事件响应机制是数据库触发器（create trigger），支持dml/ddl/系统事件的声明式绑定，但不支持自定义事件、异步回调或通用消息总线。
Oracle PL/SQL 本身不支持通用意义上的“事件驱动编程”（如 Node.js 的 event emitter 或 Kafka 消息监听），它没有内置的异步事件总线或回调注册机制。真正的事件响应能力，必须依托数据库级触发器（CREATE TRIGGER）或外部集成组件（如 GoldenGate、AQ、UTL_HTTP 轮询等）来间接实现。
PL/SQL 触发器是唯一原生事件响应机制
Oracle 数据库中，CREATE TRIGGER 是 PL/SQL 唯一能自动响应数据变更或系统事件的机制。它不是“编程模型”，而是声明式绑定：你写一段 PL/SQL 块，告诉数据库“当某表发生 INSERT/UPDATE/DELETE 时，请执行它”。
- 触发时机只能是 DML（
BEFORE/AFTER ROW/STATEMENT）、DDL（BEFORE/AFTER DDL）、登录/登出（AFTER LOGON）等有限类型，不能监听任意自定义事件 - 触发器内不能提交事务（
COMMIT），也不能调用含提交的自治事务函数（除非显式加PRAGMA AUTONOMOUS_TRANSACTION） - 避免在触发器里做耗时操作（如远程 HTTP 调用、大量日志写入），否则会阻塞 DML 执行，引发锁等待或超时
- 示例：防止 salary 被设为负数
CREATE OR REPLACE TRIGGER emp_salary_check BEFORE INSERT OR UPDATE ON employees FOR EACH ROW BEGIN IF :NEW.salary <h3>BI Publisher 的 Before/After Data Trigger 不是标准数据库触发器</h3> <p>这类触发器常被误认为是 PL/SQL 事件驱动能力的延伸，但它实际是 BIP 报表引擎在生成 XML 前后调用的独立 PL/SQL 函数，和数据库 DML 触发器无关，也不参与事务上下文。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6971" title="QuantOracle"><img src="https://img.php.cn/upload/skill/000/000/081/179120536643782.jpg" alt="QuantOracle" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill6971" title="QuantOracle" class="overflowclass">QuantOracle</a> <p class="overflowclass">63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……</p> </div> <a rel="nofollow" href="/xiazai/skill6971" title="QuantOracle" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
- 函数必须属于一个已部署的 PL/SQL 包，且返回
BOOLEAN（TRUE表示继续，FALSE中断报表执行） - 函数体中不能修改报表所依赖的数据集表（否则可能引发不可预测的并发读取问题）
- 它无法感知数据库中的实时变更，只在报表运行时被同步调用一次
- 典型用途：动态设置参数值、记录报表启动时间、检查权限状态
真事件驱动需绕过 PL/SQL 直接对接外部系统
若业务需要监听“某张表被更新”后立刻发消息、写日志、调用 API，纯 PL/SQL 无法胜任——必须引入中间层：
-
DBMS_ALERT或DBMS_PIPE：适合同实例内进程间轻量通信，但不支持跨库、无持久化、客户端需主动等待，已基本被弃用 - Oracle Advanced Queuing（AQ）：真正事务安全的消息队列，DML 可入队，另一进程或服务消费；需额外建队列表、启监听，配置较重
- GoldenGate + Kafka：如知识库所述，通过 CDC 捕获日志并投递到 Kafka，实现解耦的实时事件流；PL/SQL 完全不参与，只负责源头数据变更
- 轮询 + UTL_HTTP/UTL_TCP：在定时任务（
DBMS_SCHEDULER）中定期查变更标志位，再发起 HTTP 请求；延迟高、侵入性强，仅作兜底方案
最容易被忽略的一点：所有基于触发器的逻辑都运行在数据库服务器进程内，共享 PGA 和锁资源。哪怕只是多加一行 DBMS_OUTPUT.PUT_LINE，在高并发 DML 场景下也可能成为性能瓶颈。真要搞事件驱动，优先考虑把“响应动作”移出数据库，而不是在 PL/SQL 里堆逻辑。
