问题现象
分区表包含生成列，走全局索引回表远程扫描超过 2M，可能触发 core。 执行计划如下：
explain select/*+index(a idx)*/ count(*) ,a.c1 from t1 a where a.c2 IN(1,2) GROUP BY a.c1\G
*************************** 1. row ***************************
Query Plan: ======================================================
|ID|OPERATOR |NAME |EST. ROWS|COST |
------------------------------------------------------
|0 |HASH GROUP BY | |100 |3949035|
|1 | TABLE LOOKUP |A |19800 |3940358|
|2 | DISTRIBUTED TABLE SCAN|A(IDX)|1000000 |490656 |
======================================================
Outputs & filters:
-------------------------------------
0 - output([T_FUN_COUNT(*)], [A.C1]), filter(nil),
group([A.C1]), agg_func([T_FUN_COUNT(*)])
1 - output([A.C1]), filter([A.C2 IN (1, 2)]),
partitions(p[0-9])
2 - output([A.C3], [A.__pk_increment]), filter(nil),
access([A.C3], [A.__pk_increment]), partitions(p0)
日志中有如下信息：
observer.log:20275:CRASH ERROR!!! sig=11, sig_code=1, sig_addr=0, timestamp=1690305123859090, tid=6775, tname=TNT_L0_1001, trace_id=12378267849001-1684725832381984-0-0, extra_info=((null)), lbt=
问题原因
当索引扫描超过 2M 时，剩下的数据会走 dtl 传输，OceanBase 数据库 V3.2.3 版本将计算标记错误清除，从而触发了生成列的错误计算，进而触发了进程 coredump。
问题的风险及影响
导致 OBServer 发生 coredump，出现不可用。
影响版本
OceanBase 数据库 V3.2.3 BP6(oceanbase-3.2.3.3-106000102022111521)（包含） 到 V3.2.3 BP9(oceanbase-3.2.3.3-109000182023071410) 及中间的所有版本。 OceanBase 数据库 V3.2.4 BP5(oceanbase-3.2.4.5-105000012023081513) 之前的所有 BP 版本。
解决方法及规避方式
对问题 SQL 绑定 outline 来人工干预计划，避免走全局索引，防止走到异常的计划路径。
如果表数据量不是很大，可以由分区表修改为普通表。
执行如下语句关闭 DAS 优化。
obclient> set global "_enable_dist_data_access_service" = false。
