当前位置: 首页 > article >正文

问题小记-达梦数据库报错“字符串转换出错”处理

最近遇到一个达梦数据库报错“-6111: 字符串转换出错”的问题,这个问题主要是涉及到一条sql语句的执行,在此分享下这个报错的处理过程。

问题表现为:一样的表结构和数据,执行相同的SQL,在Oracle数据库中执行正常,到达梦数据库执行报错。

SQL语句大致如下:

SELECT "START_VAL", "END_VAL"
FROM 
(
    SELECT FLOOR(C2 / 200000) * 200000 AS START_VAL, CEIL(C2 / 200000) * 200000 - 1 AS END_VAL
    FROM T1
    WHERE C3 IN ('测试1', '测试2')
    GROUP BY FLOOR(C2 / 200000) * 200000, CEIL(C2 / 200000) * 200000 - 1
) 
WHERE START_VAL < END_VAL;

还有一个现象, 如果把最后的条件“WHERE START_VAL < END_VAL”去掉,SQL就可以正常执行,结果如下图。

客户尝试过对SQL语句中C2列使用to_number和CAST函数做显示类型转换,仍然会报错。这里不做赘述。

其实既然涉及到字符串转换出错,那问题的表象就很明显了,一定是查询语句中对应列字段真的涉及到字符串转换才会出错,数据库不会凭空报错的。

这里根据当时最终排查的结果,人工构造一批测试数据来复现下当时的情况,然后看下当时的分析过程:

--创建表
DROP TABLE IF EXISTS T1;
CREATE TABLE T1(C1 INT, C2 VARCHAR2(20), C3 VARCHAR2(50), C4 VARCHAR2(50),NOT CLUSTER PRIMARY KEY(C1));
--创建索引
CREATE INDEX IDX1 ON T1(C1 ASC,C3 ASC,C2 ASC);
--插入测试数据
DECLARE
BEGIN
    FOR I IN 1..1000 LOOP
        IF (I >= 1 AND I <= 200) THEN
            IF MOD(I, 3) = 0 THEN
                INSERT INTO T1 VALUES(I, DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10));
            ELSE
                INSERT INTO T1 VALUES(I, ABS(FLOOR(DBMS_RANDOM.VALUE(1000000000, 9999999999))), '测试1', DBMS_RANDOM.STRING('X', 10));
            END IF;
        ELSE
            IF I IN (119,120,911,10086,12345,12315,12580,96577) THEN
                INSERT INTO T1 VALUES(I, DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10), DBMS_RANDOM.STRING('X', 10));
            ELSE
                INSERT INTO T1 VALUES(I, ABS(FLOOR(DBMS_RANDOM.VALUE(1000000000, 9999999999))), '测试2', DBMS_RANDOM.STRING('X', 10));
            END IF;
        END IF;
    END LOOP;
    COMMIT;
END;
SELECT COUNT(*) FROM T1;  --共计1000条数据

注意:这里的表结构中只是本次模拟表结构随意创建的C1字段主键,实际业务场景中表字段很多,C1列也并不是主键,且表T1中包含C2和C3列的索引不止一条。表实际数据有几千万条,这里只做大致的问题模拟。

出现问题的SQL语句很简单,且只涉及到一张表,查询语句只涉及到T1表的两个字段列,分别为C2、C3,在SQL中能涉及到类型转换报错的,可以大胆判断是FLOOR和CEIL函数处理数据出现的问题。FLOOR和CEIL函数的功能如下:

这两个函数中的参数应该为数值类型才可以正常执行不报错

此时查看T1表结构,很明显,查询列C2是varchar2类型,SQL查询过程中会存在数据类型隐式转换。


通过几条SQL,来查看下数据,看看C2列数据是什么样的

先大致查询下全表数据

SELECT * FROM T1;   --查看全表数据

从上图可以得知,C2列是存在非纯数值类型的字符串的

根据过滤条件,查询下数据

SELECT * FROM T1 WHERE C3 IN ('测试1', '测试2'); --根据条件查看全表数据

根据查询结果来看,应该都是纯数字。再次查询下条数

SELECT COUNT(*) FROM T1 WHERE C3 IN ('测试1', '测试2');  --933

一共有933行

验证下C2列是否全为数值类型

SELECT COUNT(*) FROM T1 WHERE C3 IN ('测试1', '测试2') AND ISNUMERIC((C2)); --933

确认根据条件过滤后,都是数值类型,这时候使用FLOOR和CEIL理论上来说,并不应该出问题。

此时可以推测,是查询到了过滤条件“('测试1', '测试2')”之外的C2列数据,这种情况下使用FLOOR和CEIL函数一定会出现报错。如果是这种情况,就不得不看下达梦的SQL执行计划了,大概率是没有对条件提前进行过滤。执行计划如下:

1   #NSET2: [2, 1, 144] 
2     #PRJT2: [2, 1, 144]; exp_num(2), is_atom(FALSE) 
3       #PRJT2: [2, 1, 144]; exp_num(2), is_atom(FALSE) 
4         #HAGR2: [2, 1, 144]; grp_num(2), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889195957.TMPCOL0, DMTEMPVIEW_889195957.TMPCOL1) 
5           #PRJT2: [1, 2, 144]; exp_num(2), is_atom(FALSE) 
6             #HASH RIGHT SEMI JOIN2: [1, 2, 144]; n_keys(1) KEY(DMTEMPVIEW_889195959.colname=T1.C3) KEY_NULL_EQU(0)
7               #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
8               #SLCT2: [1, 50, 96]; exp11*var5 < exp11*var5-var6
9                 #SSCN: [1, 50, 96]; IDX1(T1); btr_scan(1); is_global(0)

分析以上的执行计划,执行顺序大致如下:

1、SQL执行过程中,先走了索引IDX1,直接对这个二级索引IDX进行扫描,

2、通过FLOOR和CEIL两个函数计算相关结果,并根据最外层条件带入进行过滤。

3、CONST VALUE LIST常量列表放的是查询条件C3的两个参数值'测试1'和'测试2'

4、将常量列表与第2步中过滤后的结果做HASH RIGHT SEMI JOIN

5、PRJT2获取第4步的join结果

6、HASH分组,并计算集函数

7、PRJT2获取第6步分组后的结果,至此最内层子查询已结束

8、PRJT2最外层查询结果

9、结果集输出

计划中涉及到的索引定义如下:

CREATE INDEX IDX1 ON T1(C1 ASC,C3 ASC,C2 ASC);

该索引包含了查询列和where条件列。

根据执行计划和索引定义,其实问题已经很明显了。情况和预料的一样,条件列C3的值并没有提前过滤,IDX的SSCN是包含那些不是纯数值类型的字符串的,此时用函数FLOOR和CEIL来处理数据就会报错。

那么为什么去掉最外层的where子句后,查询正常呢。让我们看下去掉“WHERE START_VAL < END_VAL”之后的执行计划

1   #NSET2: [2, 1, 144] 
2     #PRJT2: [2, 1, 144]; exp_num(2), is_atom(FALSE) 
3       #PRJT2: [2, 1, 144]; exp_num(2), is_atom(FALSE) 
4         #HAGR2: [2, 1, 144]; grp_num(2), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889195968.TMPCOL0, DMTEMPVIEW_889195968.TMPCOL1) 
5           #PRJT2: [1, 50, 144]; exp_num(2), is_atom(FALSE) 
6             #HASH RIGHT SEMI JOIN2: [1, 50, 144]; n_keys(1) KEY(DMTEMPVIEW_889195970.colname=T1.C3) KEY_NULL_EQU(0)
7               #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
8               #SSCN: [1, 1000, 96]; IDX1(T1); btr_scan(1); is_global(0)

上边的计划,可以看到,虽然也走了索引IDX1,也是SSCN对这个二级索引IDX进行扫描,但是这里SSCN后,直接与CONST VALUE LIST常量列表做了HASH RIGHT SEMI JOIN,此时已经不存在非数值的字符串了,之后再做函数计算时就不会报错。

那么这条原始SQL,在Oracle中的执行计划是什么样的呢?Oracle的计划如下:

 Plan Hash Value  : 4058097160 

-------------------------------------------------------------------------
| Id  | Operation               | Name | Rows | Bytes | Cost | Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |      |   47 |   940 |    4 | 00:00:01 |
|   1 |   HASH GROUP BY         |      |   47 |   940 |    4 | 00:00:01 |
| * 2 |    INDEX FAST FULL SCAN | IDX1 |   47 |   940 |    3 | 00:00:01 |
-------------------------------------------------------------------------

Predicate Information (identified by operation id):
------------------------------------------
* 2 - filter(("C3"='测试1' OR "C3"='测试2') AND FLOOR(TO_NUMBER("C2")/200000)*200000<CEIL(TO_NUMBER("C2")/200000)*200000-1)

上边Oracle的执行计划,可以看出来,Oracle在IDX SCAN的时候,做了C3条件过滤,然后做了FLOOR和CEIL函数处理,所以Oracle执行没有问题。

根据对达梦SQL分析的情况,如果能够正常先根据C3过滤数据,再做FLOOR和CEIL就不会报错。

依照这种思路处理的方法其实有很多,比如

方法一:再创建一个C3和C2列的索引

create index idx2 on T1(C3 ASC,C2 ASC);

执行计划如下:

1   #NSET2: [1, 1, 96] 
2     #PRJT2: [1, 1, 96]; exp_num(2), is_atom(FALSE) 
3       #PRJT2: [1, 1, 96]; exp_num(2), is_atom(FALSE) 
4         #HAGR2: [1, 1, 96]; grp_num(2), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889196107.TMPCOL0, DMTEMPVIEW_889196107.TMPCOL1) 
5           #PRJT2: [1, 50, 96]; exp_num(2), is_atom(FALSE) 
6             #NEST LOOP INDEX JOIN2: [1, 50, 96] 
7               #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
8               #SLCT2: [1, 25, 96]; exp11*var5 < exp11*var5-var6
9                 #SSEK2: [1, 25, 96]; scan_type(ASC), IDX2(T1), scan_range[(DMTEMPVIEW_889196109.colname,min),(DMTEMPVIEW_889196109.colname,max)), is_global(0)

此时的计划中可以看到是SSEK2二级索引数据定位,是能够直接过滤掉C3列数据的,之后再做函数FLOOR和CEIL不会报错。SQL语句也能正常执行。

方法二:以上创建的索引,似乎有冗余之嫌,因为已存在的IDX1已包含了C2和C3列,如果能调整IDX1索引列顺序,不增加索引的情况下会更好,但这就需要根据实际业务需求判断是否可以如此操作了。

CREATE OR REPLACE INDEX IDX1 ON T1(C3 ASC,C2 ASC,C1 ASC);

执行计划如下:

1   #NSET2: [1, 1, 96] 
2     #PRJT2: [1, 1, 96]; exp_num(2), is_atom(FALSE) 
3       #PRJT2: [1, 1, 96]; exp_num(2), is_atom(FALSE) 
4         #HAGR2: [1, 1, 96]; grp_num(2), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889196261.TMPCOL0, DMTEMPVIEW_889196261.TMPCOL1) 
5           #PRJT2: [1, 50, 96]; exp_num(2), is_atom(FALSE) 
6             #NEST LOOP INDEX JOIN2: [1, 50, 96] 
7               #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
8               #SLCT2: [1, 25, 96]; exp11*var5 < exp11*var5-var6
9                 #SSEK2: [1, 25, 96]; scan_type(ASC), IDX1(T1), scan_range[(DMTEMPVIEW_889196263.colname,min,min),(DMTEMPVIEW_889196263.colname,max,max)), is_global(0)

此时的执行计划可以看到与方法一是相同的,问题同样得到解决。

方法三:改写SQL语句,这种方式不会额外创建索引,也不会改变原有索引的字段顺序,如果业务方便进行SQL改造,也是一种不错的解决办法,下边提供两种改写方法:

(1)通过使用窗口函数来避免 GROUP BY 子句的改写方法

SELECT START_VAL, END_VAL
FROM
(
    SELECT
        FLOOR(C2 / 200000) * 200000 AS START_VAL,
        CEIL(C2 / 200000) * 200000 - 1 AS END_VAL,
        ROW_NUMBER() OVER (PARTITION BY FLOOR(C2 / 200000) * 200000 ORDER BY C2) AS RN
    FROM T1
    WHERE C3 IN ('测试1','测试2')
) AS SUBQUERY
WHERE RN = 1 AND START_VAL < END_VAL;

执行计划如下:

1   #NSET2: [1, 2, 156] 
2     #PRJT2: [1, 2, 156]; exp_num(3), is_atom(FALSE) 
3       #SLCT2: [1, 2, 156]; (SUBQUERY.RN = var2 AND SUBQUERY.START_VAL < SUBQUERY.END_VAL)
4         #PRJT2: [1, 50, 156]; exp_num(4), is_atom(FALSE) 
5           #AFUN: [1, 50, 156]; afun_num(1); partition_num(1)[DMTEMPVIEW_889196575.TMPCOL1]; order_num(1)[DMTEMPVIEW_889196575.TMPCOL0]
6             #SORT3: [1, 50, 156]; key_num(2), partition_key_num(0), is_distinct(FALSE), top_flag(0), is_adaptive(0)
7               #PRJT2: [1, 50, 156]; exp_num(3), is_atom(FALSE) 
8                 #HASH2 INNER JOIN: [1, 50, 156];  KEY_NUM(1); KEY(DMTEMPVIEW_889196577.colname=T1.C3) KEY_NULL_EQU(0)
9                   #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
10                  #SSCN: [1, 1000, 108]; IDX1(T1); btr_scan(1); is_global(0)

上边的计划,与前文所述的去掉最外层where子句“START_VAL < END_VAL”条件类似。先做SSCN,再与CONST VALUE LIST关联过滤掉C3列的数据,不会出现“字符串类型转换出错”的异常。

(2)把SQL修改为inner join的方式

SELECT A.START_VAL, B.END_VAL
FROM
    (SELECT
        FLOOR(C2 / 200000) * 200000 AS START_VAL
    FROM
        T1
    WHERE C3 IN ('测试1','测试2')
    GROUP BY FLOOR(C2 / 200000) * 200000) AS A
INNER JOIN
    (SELECT
        CEIL(C2 / 200000) * 200000 - 1 AS END_VAL
    FROM
        T1
    WHERE C3 IN ('测试1','测试2')
    GROUP BY CEIL(C2 / 200000) * 200000 - 1) AS B
ON A.START_VAL < B.END_VAL;

执行计划如下:

1   #NSET2: [68, 1, 288] 
2     #PRJT2: [68, 1, 288]; exp_num(2), is_atom(FALSE) 
3       #SLCT2: [68, 1, 288]; A.START_VAL < B.END_VAL
4         #NEST LOOP INNER JOIN2: [68, 1, 288] 
5           #PRJT2: [2, 1, 144]; exp_num(1), is_atom(FALSE) 
6             #HAGR2: [2, 1, 144]; grp_num(1), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889196622.TMPCOL0) 
7               #PRJT2: [1, 50, 144]; exp_num(1), is_atom(FALSE) 
8                 #HASH RIGHT SEMI JOIN2: [1, 50, 144]; n_keys(1) KEY(DMTEMPVIEW_889196625.colname=T1.C3) KEY_NULL_EQU(0)
9                   #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
10                  #SSCN: [1, 1000, 96]; IDX1(T1); btr_scan(1); is_global(0)
11          #PRJT2: [2, 1, 144]; exp_num(1), is_atom(FALSE) 
12            #HAGR2: [2, 1, 144]; grp_num(1), sfun_num(0); slave_empty(0) keys(DMTEMPVIEW_889196623.TMPCOL0) 
13              #PRJT2: [1, 50, 144]; exp_num(1), is_atom(FALSE) 
14                #HASH RIGHT SEMI JOIN2: [1, 50, 144]; n_keys(1) KEY(DMTEMPVIEW_889196626.colname=T1.C3) KEY_NULL_EQU(0)
15                  #CONST VALUE LIST: [1, 2, 48]; row_num(2), col_num(1)
16                  #SSCN: [1, 1000, 96]; IDX1(T1); btr_scan(1); is_global(0)

上边的计划,与第一种改写方法类似。同样是先做SSCN,再与CONST VALUE LIST关联过滤掉C3列的数据,不会出现“字符串类型转换出错”的异常。这种方法是将START_VAL和END_VAL分别拆分为两张A、B表的字段,A表和B表进行inner join。当数据量很大时,执行计划就显得不那么好看了,预估代价会非常大,但还是以最终实际执行效率为准。

最终方案:由于客户SQL可改写,最终采取了改写的方案,尽量避免了改动原表的索引。但采取的是第二种方案inner join方式。本文开头构造表数据时曾提到,客户数据量很大,两个改写的SQL第二种inner join方式的执行计划预估代价非常高,但实际执行效率是最优的,比第一种改写方案快几倍。如果在第二种改写的SQL基础上加上并行hint,效率会更高。(注:第一种改写方式的SQL加并行hint执行效率基本不变)

因此最终确定SQL改写大致如下:

SELECT /*+PARALLEL(4)*/ A.START_VAL, B.END_VAL
FROM
    (SELECT
        FLOOR(C2 / 200000) * 200000 AS START_VAL
    FROM
        T1
    WHERE C3 IN ('测试1','测试2')
    GROUP BY FLOOR(C2 / 200000) * 200000) AS A
INNER JOIN
    (SELECT
        CEIL(C2 / 200000) * 200000 - 1 AS END_VAL
    FROM
        T1
    WHERE C3 IN ('测试1','测试2')
    GROUP BY CEIL(C2 / 200000) * 200000 - 1) AS B
ON A.START_VAL < B.END_VAL;

总结:

1、在处理问题的过程中,思维要灵活,分析要细致,定位问题原因很重要。问题排错处理不能盲目进行,“‌东一榔头,西一棒子”的方式不可取,直击要害,循序渐进,才是解决问题之本。

2、达梦数据库使用过程中,数据库的优化器有待进一步改进,在实际使用过程中,需要不断人工调试,才能使业务系统保持在较好的运行状态。


http://www.kler.cn/a/450731.html

相关文章:

  • log4j2漏洞复现(CVE-2021-44228)
  • 修炼内功之函数栈帧的创建与销毁
  • 汽车IVI中控开发入门及进阶(44):杰发科智能座舱芯片
  • 个人笔记:ORM数据库框架EFCore使用示例,运行通过,附源码
  • 一个比RTK或redux更轻量级更易使用的 React 第三方状态管理工具库的配置与使用
  • idea2024创建JavaWeb项目以及配置Tomcat详解
  • 深入理解C++23的Deducing this特性(上):基础概念与语法详解
  • curl 放弃对 Hyper Rust HTTP 后端的支持
  • 《Opencv》基础操作详解(3)
  • 全国硕士研究生入学考试(考研)考研时间线之大四
  • 24.12.25 AOP
  • CASA模型相关遥感数据及MODIS NDVI、FPAR遥感产品数据时序重建
  • SpringBoot3——Web开发
  • 软件测试之压力测试【详解】
  • 安卓修改进程数 termux报错signal 9 vmos
  • webpack3 webpack4 webpack5 有什么区别
  • Java重要面试名词整理(四):并发编程(下)
  • 代理模式(JDK,CGLIB动态代理,AOP切面编程)
  • 产品经理如何做运营数据分析?
  • JVM简介—垃圾回收器和内存分配策略
  • MySQL用户授权
  • Mysql大数据量表分页查询性能优化
  • 【从零开始入门unity游戏开发之——unity篇01】unity6基础入门开篇——游戏引擎是什么、主流的游戏引擎、为什么选择Unity
  • Pytorch | 利用BIM/I-FGSM针对CIFAR10上的ResNet分类器进行对抗攻击
  • SharpDX 从入门到精通:全面学习指南
  • 【人工智能】Python中的机器学习管道:如何用scikit-learn构建高效的ML管道