背景：
客户升级了ODC的版本到4.2.3-20231225了，然后客户找过来反馈连接到一个ORACLE模式的租户下，执行“select * from dba_users”报错。
报错信息如下
排查过程：
1.首先因为该版本odc提供命令行的功能，测试了命令行执行没有问题。（这时候我怀疑的方向是新版本odc白屏的驱动有bug）
顺便看下执行计划
2.通过报错的执行记录的trace_id找到sql_audit中的信息，看下query_Sql转化有没有问题。
可以看出确实是报错了，但是sql看起来没有问题。
3.为了进一步验证，我找到了dba_users视图的原句，单独测试下。也是一样的报错，命令行可以执行。
执行计划与直接查询视图一样
然后我把cast的条件去掉了，正常执行
4.到这时候我就遇到瓶颈了，提了工单，找了相应trace_id的日志让工单同学帮忙分析。(这时候我执行了一个select sysdate from dual,然后报错了！！！！)
这时候我感觉可能是变量有什么问题，因为odc的变量是单独的，这时候我看到了一个比较可疑的信息。
显示模式变量是mysql，这个问题很大了，我这个是oracle模式的租户啊。
为了验证是这个问题，我重新配置一个数据源测试下
新配置的是正常的。这个问题我以为是oracle租户配置成mysql模式了，后来工单同学提醒了我，不同模式的话配置连接会失败的，我检查了下客户配置的原始连接，发现配置的是sys租户，也就是说登到了sys租户下查业务租户的视图所以报的错。（很大的乌龙）
结论：
其实这个问题不算复杂，甚至可以说有些low，但是结结实实花费了半天的时间，一直没搞懂因为什么原因，排查思路因为一些理所当然的推测而偏差。
行之所向，莫问远方。
