近期遇到的遇到的MPP数据库典型问题汇总整理

原创已于 2024-11-07 10:32:21 修改 · 724 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #oracle

于 2024-10-28 15:10:04 首次发布

问题1

【问题背景】XX基金列存表膨胀异常，本来1G的表，传到MPP数据库后，变成了600G，重新对表进行vacuum full之后恢复到1G

【处理过程】在dn执行

select 'cstore.'||relname from pg_class where oid = (select relcudescrelid from pg_class where relname = 'xxx' and relnamespace = (select oid from pg_namespace where nspname = 'xxx'));

第一个xxx替换成表名，第二个xxx替换成schema名称，就可以查到列存表在这个dn上的cudesc表

然后查询该cudesc表，就可以看到该dn上该列存表的CU信息

通过上面的图，发现一个CU只存储了一条数据。

【结论】理想情况下一个CU应该可以存60000条数据才最完美，因此就是这种情况导致的列存表膨胀严重。经询问，上游灌数据使用的是flink框架，流式实时框架，也就是说flink数据可能是一条一条灌进数据库的。

【后续措施】

1.使用delta表，delta表是列存表中的行存表，专门解决小CU问题。数据可以先进入delta表里，到达60000的阈值后，再灌进列存表内

2.直接用行存表，省略过多的麻烦，行存没有CU这一说，问题就能完美解决，已知是最靠谱的办法。虽然MPP数据库适合数仓AP场景，但是不敢保证业务就没有TP场景。

问题2

【问题背景】XX保险集群夯死

【问题处理】

第一天：在11这个节点，经过网络处同事反馈，有两块硬盘故障，在同一个节点故障了。但是由于MPP集群高可用机制的存在，集群本身依然能正常使用。登录集群查看11节点已经离线，集群处于降级状态。集群侧没做任何处理，商议尽快对损坏的硬盘进行修复。

第二天：数据盘到100%，集群只读不可用，原因是某个目录达到100%

【处理过程】

第一天：什么都没做，因为主备DN之间，有高可用机制，数据丢不了，但是必须要快速修复硬盘。

第二天：一个节点硬盘满了，集群不可用。将从备数据删除，腾出空间。业务正常运行，不再报错，但是此时集群是单幅本运行，十分危险的状态，必须今天搞定。

【结论】

当前集群磁盘空间过于紧张，一个节点硬盘坏掉，触发节点副本冗余机制，比如主或者备坏了，触发从节点同步数据。但是从节点空间资源十分紧张，直接把从节点挤满了，吃法只读阈值。因此，可以得知：磁盘空间过大才是元凶。

【后续措施】

1.删除用不上的业务表，但这个难度太大，必须得有个十分了解整个业务规模的人存在才行，而事实上这种人不存在！

2.脏叶率清理通过这个视图去查看

--查看脏叶率大于10%的表
SELECT * FROM pgxc_get_stat_dirty_tables(0,0) where dirty_page_rate > 10 and n_dead_tup > 1000;
 relid |         relname         | schemaname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup | dirty_page_rate
-------+-------------------------+------------+-----------+-----------+-----------+------------+------------+-----------------
 16782 | bandwidth_history_table | scheduler  |    356355 |         0 |    202068 |     154287 |      29031 |           15.84
 12050 | gs_wlm_instance_history | pg_catalog |    406464 |         0 |    234835 |     171647 |      27721 |           13.90
(2 rows)

3.经过语句排查

--查行存表
select n.nspname || '.' || c.relname FROM pg_catalog.pg_class c,pg_namespace n  WHERE c.relnamespace=n.oid and substring(array_to_string(reloptions,',') from 'orientation=row') is not null and reloptions::text not like '%internal_mask%' and c.relkind = 'r' AND c.oid > 16384;
--查列存表
select n.nspname || '.' || c.relname FROM pg_catalog.pg_class c,pg_namespace n  WHERE c.relnamespace=n.oid and substring(array_to_string(reloptions,',') from 'orientation=column') is not null and reloptions::text not like '%internal_mask%' and c.relkind = 'r' AND c.oid > 16384;

行存表60000多张，列存表几百张。

行存没有压缩，且数仓场景下，列存更合适。比如1G的行存表，转换成列存至少能省略700M大小。

经过讨论，最终走的第三个措施。将行存转换为列存，效果立竿见影。

问题3

【问题背景】

XXX证券灾备集群个别业务跑批长时间跑不出来，在过去时候，这张表是可以正常跑出来的，而且耗时大概在10分钟左右，该表数据量大概在几百亿左右。怀疑是刚刚迁移过来的有关，过去没有做过统计信息。

【处理过程】

看explain verbose的执行计划(不是实际执行，只是根据统计信息带入逻辑执行计划，去生成物理执行计划，和现实有出入，如果追求最准确，请用explain performance)，发现执行计划有很多broadcast，redistribute等算子。效率慢的点在这。但是客户的脚本在开始时就对每张表执行统计信息更新 analyze table。因此不存在统计信息未收集的问题。

这时候，部门一个大佬执行了一些命令。

ALTER TABLE table_name ALTER column_name SET STATISTICS 200; --把采样大小调整为60000
ALTER TABLE table_name ALTER column_name SET STATISTICS PERCENT 2; --把采样大小调整为2%

大意就是对所有涉及到这个业务的统计信息的采样数据量提高了不少。

执行完毕后，重跑后，问题解决。

【结论】个别一些表，因为数据过于离散，默认收集的统计信息30000条，不满足它产生最优执行计划的条件，所以需要调大

【处理措施】

多做几次analyze检查PG_STATS-》n_distinct变化是否很大，如果变化非常大的话，就得需要进行调大统计信息采样了。

这种问题遇到的概率非常低，但是遇到了要往这方面想，有这个意识。也由此得知，统计信息对是否走最优的执行计划至关重要。

问题4

【问题背景】

XXX保险业务卡死，而且卡死几十个业务，并非锁表导致的。这个问题拖得很久，临时规避方法就是遇到长时间跑不出来的杀掉，再跑就好了.

【处理过程】发现这些卡死的业务全部都依赖某一张表，这张表被其他200多个业务都依赖，晚上跑批时候，该表被依赖很多，且该表分区也特别多。

【结论】简单一句话总结这个问题：就是个别表分区数设置太多了，分区是元数据的一部分，这东西一多，别的表加载这个表的DDL加载不过来就出问题了。

原理：因为每个语句都会把访问的表定义信息缓存下来，这样再访问表信息就会比较快。如果有的DDL修改了表定义，就需要同步给其他语句，避免其他语句访问过期的表定义。这个同步机制就是通过失效消息实现的。如果一个DDL产生的失效消息过多，导致全局失效消息队列满了，其他语句不能获得全部失效消息，就只能把自己本地缓存的表信息都释放掉再重新加载。如果发生这种情况，这个语句重新释放再加载表定义就会比之前变慢。

【处理措施】

对大分区表进行瘦身。最开始考虑合并分区了，就是将多个合并成一个分区。但是这样也不好，又再次排查，将大分区表查看，发现客户手动将分区建到了2050年之后了。这个就没必要了。于是把2025年后的空分区全部干掉，从12000多个分区直接降到2000多个，自此之后，问题再无产生。

这个问题得知道，数据治理很关键，尤其是元数据治理，非常重要，影响层面是大片业务的。