odp.net managed 可通过连接字符串启用 tracelevel=6、tracefilelocation 和 traceoption=1 实现 sql 跟踪，日志中需定位 ocistmtexecute 后的 sqltext 行及 ocibindbyname 中的绑定值，但性能开销大，仅限临时诊断。
ODP.NET 本身不提供开箱即用的 SQL 通信日志开关，但可通过 Oracle 官方支持的 OracleInternal.Tracing 机制 + 客户端日志配置实现底层 SQL 捕获——前提是使用 Oracle.ManagedDataAccess（非旧版 Oracle.DataAccess），且必须在连接字符串中显式启用跟踪。
启用 Oracle.ManagedDataAccess 的客户端 SQL 跟踪
ODP.NET Managed 不依赖系统级 Oracle Client，其跟踪能力内建于程序集内部。关键不是改注册表或环境变量，而是靠连接字符串参数和配置节控制：
-
TraceLevel必须设为6（即ALL），低于此值（如4）不会记录实际 SQL 文本 -
TraceFileLocation指定绝对路径，目录需存在且进程有写权限；文件名会被自动追加时间戳，避免覆盖 - 必须添加
TraceOption=1，否则V$SQL类信息（如绑定值、执行计划摘要）不会输出 - 连接字符串示例：
"User Id=scott;Password=tiger;Data Source=orcl;TraceLevel=6;TraceFileLocation=C:\odpnet-trace;TraceOption=1;"
从 trace 文件里识别真实执行的 SQL
生成的 .trc 文件是纯文本，但格式混乱。真正要找的 SQL 出现在含 OCIStmtExecute 或 OCIBindByName 的行之后，而非开头的 SQL: 行（那只是语句模板）：
- 搜索
OCIStmtExecute→ 下一行通常是sqltext:开头的完整语句，含换行和空格缩进 - 绑定变量值在紧随其后的
OCIBindByName块中，字段名如value="123"或value="john%27%20OR%201=1"（URL 编码需解码） - 注意
sqltext中的冒号参数（如:id）是原始占位符，不是已替换的值；真实值只在 bind 块里 - 若看到
sqltext是BEGIN ... END;，说明执行的是 PL/SQL 块，需结合后续OCIStmtPrepare行确认是否含动态 SQL
为什么不用 AppDomain.CurrentDomain.FirstChanceException 或 IDbCommand.Intercept？
这些 .NET 层面的钩子无法捕获 ODP.NET 内部的 OCI 调用细节：
-
FirstChanceException只能抓到托管异常抛出瞬间，而 SQL 执行失败（如 ORA-00942）往往发生在ExecuteReader返回后，此时语句早已发往服务端 -
IDbCommand接口无拦截点；ODP.NET 的OracleCommand是密封类，无法继承重写ExecuteNonQuery - 试图用
OracleConnection.DataSource+OracleCommand.CommandText拼接日志，会漏掉所有绑定值，且无法区分同一条命令多次执行时的不同参数 - 第三方 AOP 库（如 Castle DynamicProxy）对 ODP.NET 无效，因其内部大量使用
internal方法和非虚成员
生产环境慎用 TraceLevel=6
全量跟踪带来显著性能损耗和磁盘 I/O 压力，尤其在高并发场景下：
- 每个连接独占一个 trace 文件，100 个并发连接 = 100 个持续写入的文件
- 每条 SQL 至少产生 3–5KB 日志（含堆栈、时间戳、内存地址），1 小时内可能生成 GB 级文件
- Oracle 官方文档明确警告：
TraceLevel=6仅用于诊断，禁止长期开启；建议配合TraceFileMaxSize（单位字节）和TraceFileMaxCount控制轮转 - 若只需审计 SQL 文本（不含绑定值），可用数据库端方案替代：在 Oracle 启用
AUDIT SELECT TABLE, INSERT TABLE, UPDATE TABLE, DELETE TABLE BY ACCESS，再查DBA_AUDIT_TRAIL
真正难的是把 trace 文件里的碎片化 SQL 和绑定值对齐——没有现成工具能 100% 还原原始调用上下文，尤其是批量操作或嵌套事务中。别指望日志能直接当“回放脚本”用。
