【 使用环境 】测试环境
【 客户端ODC 】
【 4.4.1 】
【问题描述】ODC解析SQL异常的慢
【复现路径】长sqlODC解析非常的慢
【附件及日志】
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
2 个赞
排查下客户端和服务端的网络，或者更换个odc版本试试
1 个赞
短sql没有问题，长sql就会很卡
1 个赞
ODC 解析长 SQL 时可能会非常慢，这可能是由于以下几个原因造成的：
-
硬解析问题：频繁对 SQL 进行硬解析，往往由于计划缓存的命中率不高，每次 SQL 请求时都需要经历一次完整的 SQL 编译过程，导致 SQL 请求耗时增加。可以通过
GV$OB_SQL_AUDIT视图中的GET_PLAN_TIME字段判断获取执行计划的耗时是否异常。正常情况下该阶段的耗时小于 0.1 ms，异常请求下该字段的耗时可超过 100 ms。 -
SQL 语句复杂度：长 SQL 语句通常更复杂，涉及到更多的表和字段，可能导致解析和执行计划生成的时间增加。
-
资源限制：ODC 在处理长 SQL 时可能会受到系统资源的限制，如 CPU、内存等。
解决方法：
-
增加计划缓存：可以通过调大计划缓存的大小系统变量
ob_plan_cache_percentage来减少硬解析的频率。系统变量ob_plan_cache_percentage用于设置计划缓存可使用的内存所占租户内存的百分比。计划缓存最多可使用内存（内存上限绝对值）= 租户内存上限 * ob_plan_cache_percentage / 100，默认值为5。
set global ob_plan_cache_percentage = 10;
-
优化 SQL 语句：尽量简化长 SQL 语句，拆分成多个较短的 SQL 语句执行。
-
检查资源使用情况：确保 ODC 和数据库服务器有足够的资源来处理长 SQL 语句。
-
使用 ODC 的执行详情功能：ODC 提供了详细的 SQL 执行详情，可以帮助您分析 SQL 执行的各个阶段耗时，从而定位具体的问题所在。
如果您已经尝试了上述方法仍然无法解决问题，建议查看 ODC 和数据库的日志，以获取更多详细的错误信息和性能数据。
详情请参考:
感谢分享
长sql解析慢点应该是预期内的。sql执行大概多久
200毫秒左右
sql复杂么文本发一下看看
文本不太好放出来、就是三个表关联，有100多个sum和60多个case when
还有每个sql有六张左右的表关联查询，六个union all会导致ODC直接卡死，需要重启才行
这个解析sql的步骤现在有开关可以关掉吗
这个功能应该不是自动触发的吧？
来学习
是吧，我每次执行他都自动先执行解析sql，然后才去库里查
目前没有关闭选项，等442版本吧，442优化了parser解析
442版本大概什么时候发布
这两天就发布出来了