ITPub博客

【问题概述】某部署了 YashanDB 的服务器在关机重启后，尝试启动数据库失败，提示如下错误：dial tcp xx.xx.xx.xx:1675: connect: connection refused此错误通常意味着数据库控制服务未正常启动。【影响范围】YashanDB 所有版本均适用【原因分析】1675 是 yasom（Yashan

【问题描述】在使用 YashanDB JDBC 驱动查询 DATE 类型字段时，如果直接使用：resultSet.getString(1);返回结果只包含日期(如 2024-05-01)，不包含时分秒。【示例现象】数据库中原始字段值为：2024-05-01 15:30:00但 getString() 返回结果却是：2024-05-01这会导致部分依赖时间精度的业务逻辑异常。【影响范围】适

【关键词】复合索引、IN 参数、执行计划、性能调优【问题描述】测试表数据量约 200 万，在 ID 和 PHONE 字段上建立了复合索引：CREATE INDEX IND_TEST1119_ID_PHONE ON TEST1119(ID, PHONE);执行以下 SQL 时性能较差：SELECT name, SUM(id) F

【关键词】YMP 迁移失败、account lock、openssl 加密不匹配【问题现象】使用 YMP 工具迁移数据时迁移失败，日志中频繁出现以下报错：invalid username/password, login deniedthe account is locked账号信息确认无误，数据库连接配置也未改动，仍持续失败。【影响版本】YashanDB 版本：23.2.3.100 ~

【关键词】XMLAGG 兼容性、WM_CONCAT 替代、SQL 聚合拼接函数【问题描述】在 Oracle 中，以下用法用于将多个行值拼接为一个字符串：XMLAGG(XMLPARSE(CONTENT T.COLUMN_NAME || ',') ORDER BY T.COLUMN_ID).GETCLOBVAL()但在迁移至

【关键词】UPDATE (子查询) SET、子查询赋值不兼容、YashanDB UPDATE 写法规范【问题描述】如下 UPDATE 语句在 Oracle 中可执行，在 YashanDB 中却报错或执行失败：UPDATE ADMIN_AUTH_ORG T1 SET T1.ORG_ID_STAN = (    &nb

【问题现象】在 GBK 编码的 YashanDB 数据库中，执行某条 insert 语句后：SQL 长时间无响应CPU 资源占满（单核 99.9%）kill session 后也无法释放查看线程状态，发现 yasdb worker 长时间占用 CPU，而会话处于 killed 状态却无法销毁。【影响版本】YashanDB 22.2.16.1YashanDB 23.3.0.61 及更早版本【根因分析

【问题现象】在客户测试过程中，同一份约 290MB 的数据文件，使用 imp 工具导入 YashanDB 时，耗时差距巨大：【影响版本】客户测试环境版本：22.2.8.3【原因分析】YashanDB 的 imp 工具在执行导入操作时，本质上是：将导入文件中的每条 SQL 一条一条通过网络传输给数据库执行。这就带来了两个问题：高频交互：每条 SQL 都会单独发起一次网络交互，交互次数远高于流式批处理

【问题描述】在 GBK 编码的 YashanDB 数据库中，尝试将包含生僻字的人名插入到 nvarchar2 字段时，出现了乱码或字符丢失的现象。例如以下操作：CREATE TABLE t1 (id INT, c1 NVARCHAR2(128)); INSERT INTO t1 VALUES (1

【问题背景】在 Oracle 中，常规只需设置 SGA 和 PGA，系统内部自动分配内存即可。但在 YashanDB 中，为了支持更灵活的内存控制，提供了更多内存参数项，便于在不同业务场景下做细致优化。然而，不少用户在调整过程中遇到报错，典型如：SQL_POOL_SIZE + DICTIONARY_CACHE_SIZE > 100 报错这类问

【问题现象】在正常环境中，通过 yasql 工具可免密登录数据库。但在删除某些用户组后，尝试连接时却出现如下报错：用户密码错误即免密登录失败。【影响范围】影响版本：YashanDB 所有版本影响场景：手动删除或修改了系统用户组配置的机器【根因分析】问题原因是：YashanDB 安装时使用的默认用户组被删除，导致当前用户所属组不再匹配原免密配置。查看当前用户组：id xp发现当前用户 xp

在 YashanDB 的生产部署中，为保证业务连续性，主备架构是最常见的高可用模式。本文将基于实际项目总结，一文讲清：主备切换的操作方式(手动与自动);一主一备与一主两备下的差异;切换过程中应注意的细节。一、典型问题场景二、适用版本YashanDB 23.2 全版本适用三、一主一备架构切换方式1. 手动切换操作（1）Switchover —— 主动切换，适用于主备同步正常所有连接将被断开

【问题现象】某生产环境数据库，在无明显业务负载的情况下，性能仅为同配置下其他节点的约 1%，查询、事务响应极慢，系统监控中发现：大量 free buffer wait 等待事件【原因分析】排查发现，系统级别参数：STATISTICS_LEVEL = ALL这是问题根因。在 STATISTICS_LEVEL 被设为 ALL 时，数据库会额外

【问题背景】某现场在通过 yasldr 工具将 NewCIS 报表数据(约 300GB)导入 YashanDB 分布式环境时，遇到频繁报错：failed to allocate 6812396 bytes memory quota for init bulkload quota导入任务中断，影响测试

当 Yashan Control Platform(YCP)运行在单机环境中，也可以使用 -rpc 模式实现离线升级，过程稳定、可控，适合标准场景快速演进。一、前提准备端口要求每台被纳管主机需开放 9072 端口，用于远程调用升级服务。二、升级前备份在升级前务必执行 YCP 组件完整备份：cd /opt/ycm/ycm/scripts sudo ./backup.sh&nbs

一、升级前准备环境要求已部署 YCP 高可用(含主节点 + 多个备节点);保证所有节点磁盘、权限、目录结构正常;确保当前为 23.2.4.100 版本，目标为 23.2.11.100。升级前备份（强烈建议）在所有节点依次执行 backup.sh 脚本，进行完整备份。/opt/ycm/ycm/scripts/backup.sh -n ycm&nbsp

【问题描述】在使用 yasql 工具执行某些复杂或拼接后的超长 SQL 时，命令行提示如下报错：YASQL-00021 input line overflow (>4000 byte at line 4)这会导致 SQL 无法执行，特别是在交互式操作时更容易触发。【原因分析】这是 yasql 工具设计上的输入限制

2024 年，随着国产数据库替代步入深水区，共享存储集群架构作为 Oracle RAC 的关键替代方向，成为系统核心数据库能力验证的试金石。我们团队对崖山数据库共享集群(YashanDB YAC)进行了系统性测试，从最初带着“怀疑”，到最终“认可”，是一次从工程视角对核心数据库产品的深度解析。一、为什么共享架构是核心系统首选？共享存储集群架构(如 Oracle RAC)具有以下优势：所有节点可对称

在实际使用中，YashanDB 常被用于各类批量处理任务。为了提升跑批效率、避免瓶颈和异常，合理的参数配置至关重要。本文整理了多个实际项目中的调优建议，供你参考和借鉴。一、适用版本YashanDB 全版本，建议版本 ≥ 23.2二、跑批性能受影响的常见场景数据写入速度慢;REDO 写入阻塞;checkpoint 频繁，影响事务响应;内存占用异常，或缓存命中率偏低;并行线程调度失衡。三、建议优化策略

【问题现象】在将一张 Oracle 表迁移至 YashanDB 后，执行插入操作时报如下错误：SQL 错误 [13] [22000]: [line: 0 column: 0] YAS-00013 value is larger than INTEGER all