oracle provider的sql拦截必须用dbcommandinterceptor而非logto，因其能直接访问dbcommand.commandtext和parameters，精准捕获nextval、隐式转换及参数绑定问题；安全提取参数需按类型分别处理；可借拦截器监控序列调用频次预警主键冲突；还能通过commandexecuted中result类型和commandtext特征识别客户端求值降级。
为什么oracle provider的sql拦截必须用dbcommandinterceptor而不是logto
logto只输出ef core语义日志，比如executing dbcommand [parameters=[@p0='xxx']]，根本看不到真实sql文本，也没法拿到dbcommand.commandtext和dbcommand.parameters。而oracle调试最需要的是：确认是否用了nextval、有没有隐式类型转换、参数绑定是否正确。dbcommandinterceptor能直接访问原始命令对象，是唯一可靠入口。
如何安全提取Oracle参数化SQL用于日志或分析
别手动拼接DbCommand.CommandText和DbCommand.Parameters——Oracle对DATE、NUMBER、RAW类型的参数绑定很敏感，p.Value.ToString()可能返回空字符串或时区错误值。实际做法：
- 开发环境快速验证：
command.Parameters.Cast<dbparameter>().Select(p => $"{p.ParameterName} = {(p.Value == DBNull.Value ? "NULL" : p.Value?.ToString() ?? "NULL")}").ToArray()</dbparameter> - 生产环境必须用
Convert.ToString(p.Value, CultureInfo.InvariantCulture)处理数值，((DateTime)p.Value).ToString("yyyy-MM-dd HH:mm:ss.fff")格式化日期 - 遇到
byte[]或Guid，先判断类型再转：p.Value is byte[] b ? $"0x{BitConverter.ToString(b).Replace("-", "")}" : p.Value?.ToString()
Oracle序列主键重复问题怎么通过拦截器提前发现
Oracle Provider 5.x/6.x在HiLo模式下会缓存序列值，但SEQ_SYSUSER.NEXTVAL只在缓存耗尽时执行，导致第11次插入才触发——这期间如果应用重启或并发写入，就可能撞上重复主键。拦截器能抓到这个关键信号：
- 监听
CommandExecuting中command.CommandText.Contains("NEXTVAL")的语句 - 记录每次
NEXTVAL调用的时间戳和上下文ID（如context.GetType().Name） - 当同一序列10秒内被调用超过1次，立刻打告警日志——说明缓存策略失效或并发异常
- 注意：不要在拦截器里改
command.CommandText去“修复”序列逻辑，Oracle序列行为由驱动层控制，强行改SQL会导致ORA-00936
禁用客户端求值失败时，拦截器怎么帮定位翻译断点
Oracle Provider对某些LINQ表达式（比如string.Contains带变量、DateTime.DayOfYear）不支持服务端翻译，会静默降级到客户端求值。这时DbCommandInterceptor.CommandExecuted里result类型是IEnumerable<t></t>而非DbDataReader，就是信号：
- 检查
command.CommandText是否为空或极短（比如只有SELECT * FROM DUAL）——说明EF根本没生成查询，全在内存算 - 对比
IQueryable<t></t>变量的.ToString()输出，看是否含Where、Select等未翻译节点 - 在
CommandExecuted里加断点，观察command.CommandType是否为CommandType.Text且command.CommandText长度
真正要解决，得回代码里把.Where(x => x.Name.Contains(searchTerm))拆成.Where(x => EF.Functions.Like(x.Name, $"%{searchTerm}%"))，Oracle Provider 6.0+才支持这个函数映射。
