【 使用环境 】生产环境 及 测试环境
【 OB or 其他组件 】OB-for oceanbase
【 使用版本 】4.2.3
【问题描述】 使用SELECT TO_CHAR(CREATE_TIME , ‘YYYY “年” MM “月” DD “日”’) from TEMP;
就出现乱码，数据库字符集为GBK
【复现路径】问题出现前后相关操作
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
在这个情况下，您遇到的是 OceanBase 数据库中的字符集问题。当使用 TO_CHAR 函数格式化时间戳并返回字符串时，如果数据库的字符集与客户端的字符集不匹配，可能会导致乱码现象。为了更好地诊断这个问题，我们可以使用 obdiag 工具来收集相关的日志信息。
根因分析场景: [无] （由于当前情况更适合通过配置检查而非直接使用 obdiag 进行根因分析）
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”
请注意，上述命令中的 -h127.0.0.1 -P2881 -utest@test -p****** -Dtest 和 trace_id 需要替换为您实际的数据库连接信息和事务追踪ID（如果有的话）。这个命令将会收集与 SQL 性能有关的日志，包括查询计划、执行时间和等待事件等，这对于诊断字符集导致的问题可能有一定的辅助作用。
同时，为了更有效地解决您的问题，我需要了解以下几点额外的信息：
SELECT 语句时，是否设置了任何会话级别的字符集参数？以上信息将有助于我们更快地定位问题，并给出更准确的解决方案。如果方便的话，请也提供通过 obdiag 收集的日志文件。
附上敏捷诊断工具 obdiag 使用帮助链接
TEMP表的表结构发一下
CREATE TABLE “AIPTEST”.“TEMP” (
“CREATE_TIME” DATE DEFAULT NULL
) COMPRESS FOR ARCHIVE REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0;
看一下操作系统字符集是什么，使用的proxy连接的ob么
使用的windows操作系统正常使用的odc链接的数据库，数据库的字符集是GBK
数据库是oceanbase for oracle 版本是4.2.3
字符集问题
