问题小记-达梦数据库报错“字符串转换出错”处理
最近遇到一个达梦数据库报错“-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、达梦数据库使用过程中,数据库的优化器有待进一步改进,在实际使用过程中,需要不断人工调试,才能使业务系统保持在较好的运行状态。