OracleDependency注册CQN失败的根本原因是数据库端权限或配置缺失，而非.NET代码逻辑错误；必须确保应用用户拥有CHANGE NOTIFICATION、SELECT ANY DICTIONARY、DBMS_CHANGE_NOTIFICATION.EXECUTE权限，QRCN还需表级SELECT权限，且COMPATIBLE≥11.0.0、dml_locks≠0，注册语句须含ON COMMIT且禁用ROWID。
根本原因通常是注册环节权限或配置缺失，而不是代码逻辑本身出错。
ODP.NET注册CQN前必须确认的权限项
Oracle 19c中，OracleDependency 能否成功注册连续查询通知（CQN），不取决于.NET代码写得是否漂亮，而取决于数据库端是否真正“允许”该用户发通知。常见遗漏点：
-
CHANGE NOTIFICATION权限未授予应用连接用户（不是DBA用户，是实际执行查询的那个账号） -
SELECT ANY DICTIONARY缺失 —— CQN内部需访问V$CHANGE_NOTIFICATION_REGS等视图 - 若注册的是QRCN（查询结果变更通知），用户还需对被查询表有
SELECT权限，且该表不能是GLOBAL TEMPORARY表 - 使用PL/SQL方式注册时，
DBMS_CHANGE_NOTIFICATION包的EXECUTE权限必须显式授予，不能靠RESOURCE角色隐式继承
注册语句必须包含ON COMMIT且禁用ROWID选项
ODP.NET底层调用的是OCI接口，它对CQN注册语句的语法敏感度远高于PL/SQL。以下两点极易被忽略：
- 注册查询必须以
ON COMMIT结尾，例如：SELECT * FROM orders WHERE status = 'PENDING' FOR UPDATE❌；正确写法是：SELECT * FROM orders WHERE status = 'PENDING'ON COMMIT - 不能带
ROWID选项 —— ODP.NET不支持解析含ROWID的注册结果，会导致静默失败（无异常，但OnChange事件永不触发） - 聚合、分析函数、
DISTINCT、子查询在QRCN中默认被禁用，除非明确启用qrcn_mode => DBMS_CHANGE_NOTIFICATION.QUERY_MODE并设为DBMS_CHANGE_NOTIFICATION.BEST_EFFORT
OracleDependency 实例生命周期管理不当
很多人把OracleDependency 当成一次性对象，注册完就丢弃，这是最典型的失效原因：
-
OracleDependency必须在整个监听周期内保持存活 —— 它不是注册完就“启动后台服务”，而是依赖其内部持有的数据库会话维持注册状态 - 一旦关联的
OracleCommand或OracleConnection被Dispose()或GC回收，注册立即失效，且数据库不会主动通知客户端 - 推荐做法：将
OracleDependency作为单例或长生命周期对象持有，并在应用退出前显式调用Unregister() - 不要在Web请求作用域（如ASP.NET Core Controller）中创建和释放它 —— 请求结束即断连，通知必然丢失
Oracle 19c特有的兼容性陷阱
即使所有步骤看起来都对，19c仍可能因参数级限制拒绝注册：
-
COMPATIBLE参数必须 ≥11.0.0（19c默认满足，但升级后可能被误改回旧值），检查：SELECT value FROM v$parameter WHERE name = 'compatible' -
dml_locks参数不能为0（19c默认是1000，但某些精简版安装或容器镜像可能设为0），检查：SELECT value FROM v$parameter WHERE name = 'dml_locks' - 若数据库启用了
ENABLE_DDL_LOGGING=TRUE，部分DDL类通知（如ALTER TABLE）可能被延迟或合并，这不是bug，是设计行为
真正难排查的，往往不是“为什么没通知”，而是“为什么注册没报错却没生效”——因为Oracle对非法CQN注册的处理是静默忽略，而非抛异常。务必逐项验证数据库端的注册状态：SELECT * FROM USER_CHANGE_NOTIFICATION_REGS，空结果集就是最直接的诊断信号。
