当一个SQL执行时首先会进入查询缓存查看之前是否执行过该语句，如果执行过则会以key-value的形式保存在缓存中，key是查询语句，value是查询结果如果缓存命中则直接返回结果，如果查询语句不在缓存中继续后面的流程大多数情况下我们不推荐使用查询缓存，因为缓存失效非常频繁，只要一个更新，那么这个表上所有的缓存都会失效，吐过数据的更新比较多，那么缓冲命中的效率很低，不断的在失效在MySQL中提供了参数 query_cache_type 参数来设置，默认是 DEMAND ，表示对默认的SQL都不使用查询缓存，如果要对特的语句进行缓存查询，则可以使用 SQL_CACHE 来显示的指定

【功能模块】【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

1、备份<%SQL="backup database 数据库名 to disk='"&Server.MapPath("backup")&"\\"&"backuptext.dat"&"'"set cnn=Server.createobject("adodb.connection")cnn.open "driver={SQL Server};Server=服务器名;uid=sa;pwd="cnn.execute SQLon error resume nextif err<>0 thenresponse.write "错误："&err.Descriptingelseresponse.write "数据备份成功！"end if%>绿色c hinaip ower. comAYrCJ6B2、恢复<%SQL="Restore database 数据库名 from disk='"&Server.MapPath("backup")&"\\"&"backuptext.dat"&"'"set cnn=Server.createobject("adodb.connection")cnn.open "driver={SQL Server};Server=服务器名;uid=sa;pwd="cnn.execute SQLon error resume nextif err<>0 thenresponse.write "错误："&err.Descriptingelseresponse.write "数据恢复成功！"end if%>

org.postgresql.util.PSQLException:ERROR: dn_6375_6376:uncommitted xmin 10500360088 from before xid cutoff 5468852135 needs to be frozen。请问这个报错是什么导致的，怎么解决？

联邦计算场景随着MPC、隐私计算等概念的流行， 诸多政府机构、金融企业开始考虑参与到多方计算的场景中， 扩展数据的应用价值。以下面这个场景为例， 银行可能希望获取水电局和自己银行内储户的数据，来综合计算得到各公司的信贷评分等级。那么银行可能希望执行如下sql，来得到信贷评分。select 0.5*c.资助金额*0.3+0.4*a.贴息金额*0.3+0.2*a.标的金额*0.3+(0.05*b.水费缴纳金额+0.05*b.汽费缴纳金额+0.05*b.电费缴纳金额)*0.1 from partyA.tax a. partyB.amount b on a.id = b.id问题上述联邦计算场景中， 需要做join操作，来进行水电局和银行数据的关联。传统方案中， 会在TEE中进行碰撞操作，得到关联数据，再进行计算。但水电局的用户数量是非常多的，而银行的储户数量相对来说是有限的。 因此实际关联数量是以银行储户数量为准。如果将水电局的数据如果全部上传到TEE中， 则软硬件之间的传输代价会非常大，且这个过程将非关联记录的敏感数据也会一并带上来。另外银行的储户身份也可能是高敏感隐私。解决使用PSI方案（隐私保护集合交集）可以有效地解决上述两个问题。PSI通常具有以下三个特点：半可信场景：数据双方不愿意暴露所有数据，仅希望求得数据集合交集数据最小化：除了数据集合交集以外的数据不能泄露给任意一方安全双方计算：参与计算的双方需要共同实现一套安全的计算协议，以保证数据的安全性。具体流图如下：该过程可保证 A方和B方的id在纯密文的场景下进行碰撞， 得到关联id集合， 并以此为依据输出。应用当前tics的联邦计算业务已支持psi的应用。联盟管理页面，管理员开启“高级别隐私保护” 。 当开启之后，如果满足PSI-JOIN的sql语句， tics便会选用psi的方式构建执行计划，进行join碰撞，再继续后续的计算。创建作业，执行对应包含sql-join作业执行作业，可以看到tics系统的DAG图中，展示了psi的全部过程。 输出结果与直接做join的结果是一致的。

如何获取 DWS 集群各项资源指标的使用率，比如集群当前CPU使用率达到多少，内存达到多少，IO占用率多少，网络速率多少？以及单条SQL运行时占用的这些指标资源如何获取？

org.postgresql.util.PSQLException:ERROR: dn_6375_6376:uncommitted xmin 10500360088 from before xid cutoff 5468852135 needs to be frozen。请问这个报错是什么导致的，怎么解决？

对于复杂、效率低的sql语句，我们通常是使用explain sql 来分析sql语句，这个语句可以打印出，语句的执行。这样方便我们分析，进行优化table：显示这一行的数据是关于哪张表的ref：非唯一性索引扫描，返回匹配某个单独值的所有行，常见于使用非唯一索引即唯一索引的非唯一前缀进行查找；eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配，常用于主键或者唯一索引扫描；const，system：当MySQL对某查询某部分进行优化，并转为一个常量时，使用这些访问类型。如果将主键置于where列表中，MySQL就能将该查询转化为一个常量。possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句key： 实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MySQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MySQL忽略索引

【关 键 词】： 连接数超限【适用版本】：GaussDB A所有版本及 FusionInsight HD elk组件【告警信息】：MPPDB连接数超限【问题现象】: FI告警.连接数超限,业务侧报错连接超时或者链接MPPDB数据库失败【参数说明】  max_connections  连接池机制与设置说明: https://bbs.huaweicloud.com/forum/thread-93442-1-1.html【场景分析】1.1          查看活跃语句的并发,发现CN节点上连接是否分布均衡与各个CN上的活跃连接总数,查看count列是否接近于max_connections的设定值select coorname,  usename, datname, enqueue , count(*) from pgxc_stat_activity  where  usename <> 'omm' and state = 'active' group by coorname, usename, datname, enqueue ;1.2    查看CN的max_connections参数,是否在合理范围内, CN节点默认值800，DN节点默认值为5000,DN最大连接数=CN最大连接数*CN个数.如果报连接数超限的节点为DN,首先排查DN节点的参数,修改该参数需要重启集群生效修改参数办法: su - omm && source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile                          gs_guc set -Z coordinator -N all -I all -c "max_connections = 800"                          gs_guc set -Z datanode -N all -I all -c "max_connections = 4000"1.3   查看session_timeout.语句在完成后会状态会变成idle状态,idle状态的语句也会占用一个连接,在达到session_timeout设置的时间后,会自动清理连接,session_timeout设置不合理,会影响连接池的复用.show  session_timeout;su – ommsource /opt/Huawei/Bigdata/mppdb/.mppdbgs_profilegs_guc reload -Z coordinator -N all -I all -c "session_timeout=600"   --单位秒1.4     安装有LVS的集群,通过client 客户端做轮询测试,查看LVS是否分发到所有   的CN节点;没有client客户端的,可以通过DS连接LVS地址测试,轮询一个CN后,需要断开DS连接,重新登录,DS测试比较慢.如果不能轮询到所有的CN节点,需要排查LVS故障.1.4.1 测试语句select pgxc_node_str();1.4.2 通过LVS,判断业务是否轮询到所有的CN:    在主LVS主机: ipvsadm –Lnc |grep  CNIP , destination包含所有的CN地址,说明轮询没有问题1.5   根据client_address排查业务IP,业务侧查看配置文件是否配置的是LVS虚拟IP地址,如果不是,修改业务的配置文件.1.5.1 查找连接最多的业务地址:Select client_addr,count(*)  from pgxc_stat_activity  where  usename <> 'omm' and state = 'active' and coorname=’CN_5002’ group by 1;1.5.2 通过LVS,判断业务是否直连CN:    在主LVS主机: ipvsadm –Lnc |grep  业务IP ,destination:只有一个地址,说明业务直连了CN1.6     排查语句长期占用CN的原因,可以查询等待视图,查看语句执行时间和等待事件:1.6.1  查看长时间执行的语句:select coorname, usename, client_addr, sysdate - query_start as dur,pid,enqueue, query_id, replace(query, chr(100), ' ') from pgxc_stat_activity where usename!= 'omm' and state = 'active' order by dur desc;1.6.2       查看等待视图,排查语句慢的原因:select sysdate-query_start as dur,waiting,enqueue,state,a.query_id,replace(substr(query, 0, 100), chr(100), ' '),node_name,thread_name,tid,lwtid,wait_status,wait_event  from pgxc_stat_activity a, pgxc_thread_wait_status b  where state = 'active' and  a.query_id = b.query_id and a.query_id <> 0  order by 1 desc;           找到慢的语句之后,对语句进行优化,加快语句的执行速度,减少占用连接池的时间1.7     判断是否是语句残留,导致连接池被占用select coorname,now()-query_start as dur,state,query_id,query,waiting,enqueue from PGXC_STAT_ACTIVITY where usename <> 'omm' and state <> 'idle' order by dur desc;      活跃视图的active和idle,总数量并不高,但是连接数还是不释放,查看state <> 'idle',发现一些执行时间超长,状态为 idle in transaction语句,qury_id为0,waiting为 f,可以认定为是语句残留,可以通过kill  语句所在的CN解决,该方法会中断目前在该CN上执行的语句,对业务造成影响.   登录到CN对应的主机:            1.8    用户设置参数限制                 select rolname,rolconnlimit from pg_authid;                alter role username CONNECTION LIMIT -1;             【建议和总结】   连接数超限,会影响新的连接接入,快速定位可以减少业务受影响的时间.排查过程需要DBA和业务运维配合,但是业务的运维和开发可能不是一个人,判断业务是否直连CN反馈过程可能较慢,文档提供好了在数据库侧快速定位的方法.问题总结如下:   1.业务网在完成查询之后如果没有特殊需求,最好快速释放连接,根据业务需求设置设置session_timeout为合理值   2.排查过程中容易忽略语句残留的状况,根据state <> 'idle'和语句执行时间,可以判断是否是语句残留.当业务侧发生过异常中断时,容易发生语句残留的状况   3.在多业务使用集群的状况下,不能确认业务名,可以根据 client_addr,找到接入地址,根据IP地址判断业务属于哪个公司   4.其余状况分为两类:一是业务没有控制并发,连接数增大,导致达到最大值;二是语句执行慢,语句常时间占用资源,需要优化SQL语句,减少SQL占用集群资源时间 

1. 数据压缩一些面向列的数据库管理系统不使用数据压缩。然而，数据压缩确实在实现卓越性能方面发挥着关键作用。除了在磁盘空间和CPU消耗之间做出不同权衡的高效通用压缩编解码器外，ClickHouse还为特定类型的数据提供专门的编解码器，这使得ClickHouse能够与时间序列数据库等更利基数据库竞争并优于它们。ClickHouse 是列存数据库，故天然支持面向列的数据压缩，不同列针对不同的数据类型可以采取不同的压缩算法，这都是常规的操作~ 其他 OLAP 引擎都是这么干的关于列式存储请参考我的博客——列式存储和行式存储有什么区别？2. 磁盘存储数据按主键对数据进行物理排序，可以以不到几十毫秒的延迟提取其特定值或值范围的数据。一些面向列的数据库管理系统（如SAP HANA和Google PowerDrill）只能在RAM中工作。这种方法鼓励分配比实时分析所需的更大的硬件预算。ClickHouse旨在用于常规硬盘驱动器，这意味着每GB的数据存储成本较低，但如果可用，SSD和额外的RAM也得到充分使用。简单来说就是内存不够磁盘来凑，这个也不新鲜，Spark SQL 也属于 OLAP 引擎，也支持内存磁盘的弹性存储。3. 多核并行处理大型查询自然并行化，占用当前服务器上可用的所有必要资源。ClickHouse 本质上属于 MPP 架构，MPP 架构是基于 SMP 架构的，SMP 架构决定了多核并行处理的能力。关于 SMP 和 MPP 请参考我的博客从系统架构角度出发，服务器该如何分类？MPP 是什么？4. 多台服务器上的分布式处理在ClickHouse中，数据可以驻留在不同的分片上。每个分片可以是一组用于容错的复制品。所有分片都用于并行运行查询，对用户透明。ClickHouse 是 MPP 架构，故天然支持大规模数据的并行分布式处理。5. SQL 支持ClickHouse支持基于SQL的声明式查询语言，在许多情况下与ANSI SQL标准相同。支持的查询包括GROUP BY、ORDER BY、FROM中的子查询、JOIN子句、IN运算符和标量子查询。编写时不支持相关（依赖）子查询和窗口函数，但将来可能会可用。基本上所有的 OLAP 引擎都支持 SQL，这没啥新鲜的。6. 向量化计算引擎数据不仅由列存储，还由向量（列的一部分）处理，从而实现较高的CPU效率。建议看看我的这篇博客——即时编译器的向量化优化是什么？SIMD 到底是什么？7. 实时数据更新ClickHouse支持带有主键的表。为了快速对主键的范围执行查询，使用 Merge Tree 对数据进行增量排序。因此，数据可以不断添加到表中。摄入新数据时是无锁。MergeTree 来源于 MySQL 里面的 MyISAM，专栏后面会重点介绍 CK 中 MergeTree 的实现原理。8. 主要索引通过主键物理排序数据可以以低延迟（不到几十毫秒）为其特定值或值范围提取数据。类似 MySQL 里面的主键，这个要习惯，因为 CK 就起源于 MySQL 中的 MyISAM，早期的很多特性都比较类似于 MySQL。9. 次要索引与其他数据库管理系统不同，ClickHouse中的辅助索引不指向特定的行或行范围。相反，它们允许数据库提前知道某些数据部分的所有行与查询过滤条件不匹配，并且根本不读取它们，因此它们被称为数据跳过索引。10. 适合在线查询大多数OLAP数据库管理系统不针对具有亚秒延迟的在线查询。在替代系统中，报告构建时间为数十秒甚至几分钟，通常被认为是可以接受的。有时，离线编写报告需要更多（提前或以“稍后回来”回应）。在ClickHouse中，低延迟意味着可以在用户界面页面加载的同时，立即处理查询，而无需尝试提前准备答案。换句话说，在线查询。类似功能的 OLAP 引擎还是挺多的，不过 CK 还是 ROLAP 中的 NO.111. 支持近似计算ClickHouse提供了各种以准确性换取性能的方法用于近似计算不同值、中位数和分位数的聚合函数。根据数据的一部分（样本）运行查询并获得近似结果。在这种情况下，从磁盘检索的数据比例较低。为数量有限的随机密钥运行聚合，而不是为所有密钥运行聚合。在数据中密钥分发的某些条件下，这在使用更少资源的情况下提供了相当准确的结果。12. 自适应 Join 算法ClickHouse自适应地选择如何加入多个表，更倾向于 hash join 算法，如果有一个以上的大表，则返回 merge join 算法。13. 数据复制和数据完整性支持ClickHouse使用异步多主复制。写入任何可用的副本后，所有剩余的副本都会在后台检索其副本。该系统在不同副本上维护相同的数据。大多数故障后自动恢复，或在复杂情况下半自动进行。14. 基于角色的访问控制ClickHouse使用SQL查询实现用户帐户管理，并允许基于角色的访问控制配置，类似于ANSI SQL标准和流行的关系数据库管理系统。15. 官方认证的简直就是缺点的特性不支持完整的事务。缺乏以高速率和低延迟修改或删除已插入的数据的能力。支持批量删除和更新可用于清理或修改数据，例如，遵守GDPR。稀疏索引使ClickHouse对通过 key 检索单行的点查询不那么有效。

对于性能问题，这边习惯将其按照范围和影响分为单点性能问题和系统级性能问题，单点性能问题大多直接转变成单SQL调优，而系统级性能问题因其复杂性往往处理起来比较费时费力，在此根据历史性能问题的处理经验总结一份套路，旨在指导大家在碰到DWS性能问题时有法可依，主要包含问卷和三阶段排查两个部分。问卷主要为和客户快速确认性能慢的初步信息，用来快速排除低级的非数据库服务侧的问题，并大致明确问题范围和影响：维度目标确认项where（哪里慢）明确是否慢在数据库侧，即服务侧如何统计业务执行时间是否为DWS库内执行慢是否涉及上下游供数是否应用侧数据处理慢who（都谁慢）明确慢的业务范围及影响是否单SQL慢是否特定类SQL慢（例vacuum full）是否实时查询慢（例报表）是否数据入库慢（例insert）是否所有业务慢what（咋个慢法）明确性能对比基线与历史比与其他集群比（例测试集群比）与其他部署形态比（线上线下）与其他产品比（例oracle）与经验值比（例空表查询慢）Why（为何变慢）明确是否存在显在外部变化（如有反馈变更，则主要针对变化展开分析）是否本身为新业务是否近期有新业务上线是否近期业务调度发生变化是否近期业务数据量突增是否近期业务访问量突增（并发）是否近期服务变更（升级、扩容、巡检等）是否近期运行环境变更（安装服务、监控、杀毒软件等）When（慢的时间）明确问题触发规律（如果为偶发、定期慢，则需部署监控、探针）是否一直慢是否固定时间慢（高峰、跑批时）是否随机偶发慢在完成上面的问卷并明确问题范围和影响后，如果确定是整体业务性能都比历史慢且未识别出明显的业务变化，则开始后续三阶段排查。阶段一 集群健康度1、集群状态集群状态异常、不均衡均会影响业务的整体运行效率，所以确定集群状态正常和均衡是整体性能稳定的首要保证。Check项异常值说明Check方法Cluster stateUnavailable集群不可用影响业务整体进度cm_ctl query –CvDegraded降级的Deleted/Building状态影响集群均衡NormalCatchup状态影响IO资源的均衡BalancedNo主备倒换影响DN实例的均衡 处理方式：集群修复、集群均衡（主备切换）集群修复：https://bbs.huaweicloud.com/blogs/detail/198733主备切换：https://bbs.huaweicloud.com/forum/thread-140502-1-1.html2、可服务性在检查集群状态正常的情况下，还存在服务对外不可提供服务的可能，从而影响整体业务进度，最常见为某CN hang，所以通过建连、建表来快速确认CN、DN的基础可服务性。Check项异常值说明Check方法建连（连接CN\DN）连接hangCheck 客户端连接服务是否正常gsql连接建表（DDL）建表hangCheck CN与CN/DN间交互是否正常create table test_tbl(a int,b int,c varchar(100));drop table test_tbl; 处理方式：gstack保留hang实例进程栈后，重启或隔离CN/DN进行快速恢复单节点重启或隔离： https://bbs.huaweicloud.com/forum/thread-147714-1-1.html单实例重启或隔离： https://bbs.huaweicloud.com/forum/thread-147713-1-1.html多CN隔离：https://bbs.huaweicloud.com/forum/thread-147718-1-1.html3、资源瓶颈性能问题尤其是系统级性能问题大多伴随着某类系统资源（CPU/IO/内存/网络）的瓶颈，快速检查集群的整体资源使用情况有利于快速缩小问题范围。1、线下集群的资源使用情况使用FI Manger管理界面查看：2、公有云集群资源使用情况使用DWS-console管理界面查看：3、混合云集群资源使用情况可随机抽取CN/DN使用top/iostat/free初步排查资源使用情况。 处理方式：对整体的资源使用情况有大致的把握后继续进行后续排查，并在后续每个排查措施实施后，观察对应飙高资源是否回落。阶段二 业务状态1、烂SQL清理Check项异常值说明Check方法长时间执行的业务SQL执行时间超过阈值（根据实际场景确定，例如1h）长时间执行的sql大多会长期占用系统资源SELECT usename,coorname,now() - query_start AS runtime,substr(query, 1, 100) AS query,pid,query_id,waiting,enqueueFROM pgxc_stat_activityWHERE STATE = 'active'AND usename <> 'omm'AND usename <> 'Ruby'ORDER BY runtime DESC LIMIT 50;处理方式：和客户沟通对执行时间长的sql进行查杀，观察其他业务和资源恢复情况，若恢复则进入对被查杀SQL的调优环节，否则继续进行后续排查业务SQL查杀：https://bbs.huaweicloud.com/forum/thread-147712-1-1.html 2、业务阻塞点Check项异常值说明Check方法整体业务阻塞情况1）长时间wait某个节点2）长时间wait某类资源多次执行，观察是否长期停留 在wait特定对象的状态SELECT now(),wait_status,wait_event,count(*) AS cntFROM pgxc_thread_wait_statusWHERE wait_status <> 'wait cmd'AND wait_status <> 'synchronize quit'AND wait_status <> 'none'GROUP BY 1,2,3ORDER BY 4 DESC limit 50;其中等待状态含义参见：https://support.huaweicloud.com/devg2-dws/dws_0402_0863.html部分状态举例说明：wait node：等待其他CN/DN节点，可能为慢节点wait io：等待读写，可能为IO问题wait pooler：等待内部建连，可能为网络问题acquire lock：等锁，对相同表并发操作导致acquire lwlock：等轻量级锁，并发高导致内部问题1：针对IO、网络等资源方面的问题参考阶段三 系统状态中处理问题2：针对LOCK的问题参考：锁等待场景：https://bbs.huaweicloud.com/blogs/233114死锁的场景：https://bbs.huaweicloud.com/blogs/2288403、业务并发Check项异常值说明Check方法整体并发负载情况1）并发数长期维持高位2）各CN上业务分布不均执行多次，check整体负载及CN负载均衡SELECT usename,coorname,enqueue,count(*)FROM pgxc_stat_activityWHERE STATE = 'active'AND usename <> 'omm'AND usename <> 'Ruby'GROUP BY 1,2,3ORDER BY 4 desc;问题1：并发高（在前面明显的烂SQL已经清理的情况下）如伴随着cpu、内存等整体资源瓶颈，则需降低业务并发度并继续观察（并发值根据实际业务情况实测、压测最终明确）：CN级并发调整(max_active_statements)：https://bbs.huaweicloud.com/blogs/179009 用户级并发调整：https://bbs.huaweicloud.com/forum/thread-74904-1-1.html问题2：CN上分布不均（部分CN排队严重）线下建议部署LVS：https://bbs.huaweicloud.com/forum/thread-145807-1-1.html无法部署LVS和ELB的场景建议客户将应用业务分散到不同CN执行（应用指定）4、业务排队Check项异常值说明Check方法业务排队业务排队严重多次执行，Check排队情况及持续排队的缓解情况SELECT,usename,,resource_pool,enqueue,count(*)FROM public.pgxc_session_wlmstat()WHERE attribute != 'Internal'AND enqueue != 'None'AND status = 'pending'GROUP BY 1,2,3ORDER BY 4 DESC;说明：pgxc_session_wlmstat需手动创建，请参考https://bbs.huaweicloud.com/blogs/278874问题1：Global状态的排队多：触发全局max_active_statements阈值问题2：Respool状态的排队多：触发资源池内存、并发限额，评估该用户使用资源合理性触发资源池内存限额触发资源池max_active_statements限额触发资源池max_dop限额(仅针对简单语句)问题3：CentralQueue状态的排队多：触发全局内存max_dynamic_memory限制，评估内存参数设置及业务使用内存情况其中针对Global状态排队多问题：根据资源余量情况决策是否调大max_active_statements其中针对Respool及CentralQueue类问题参考https://bbs.huaweicloud.com/blogs/222017阶段三 系统状态这里所说系统状态主要指系统CPU、IO、内存、网络等系统资源使用情况，导致这些系统资源不足的场景非常之多，且之间互相影响。Check项Check方法异常值CPUtop整体或部分>80%内存top/free整体或部分>70%IOiostat/iotop>90%/长期100%网络ping/gsar/neststat重传、丢包严重1、资源高（cpu/io/mem）1）单节点资源瓶颈分针对DWS分布式场景，单节点资源瓶颈大多为硬件、OS故障、业务倾斜导致，主要进行以下排查：硬件、OS侧排查重点：排查bmc日志（常见IO问题如磁盘告警、磁盘读写策略、CPU节能模式）排查messages日志（例历史上出现过的主板故障导致CPU高）业务侧排查重点：排查存储倾斜：https://bbs.huaweicloud.com/blogs/183585排查计算倾斜：https://bbs.huaweicloud.com/blogs/254845排查Sharding业务（分布列作为过滤条件的点查）2）排除taishan问题泰山服务器有已知的网卡、内存等方面问题，需排查是否做过加固： https://support.huawei.com/enterprise/zh/bulletins-product/ENEWS20000077433）排除异常进程使用top/iotop等工具明确消耗资源的进程为gaussdb进程，历史上出现过杀毒软件、ssh进程、getClientInfo进程导致CPU飙高的情况。https://bbs.huaweicloud.com/forum/thread-74914-1-1.html4）抓top资源业务Top CPU消耗的业务抓取方法： https://bbs.huaweicloud.com/forum/thread-70939-1-1.htmlTop IO消耗的业务抓取方法：https://bbs.huaweicloud.com/forum/thread-149502-1-1.htmlTop内存消耗的业务抓取方法：https://bbs.huaweicloud.com/forum/thread-110215-1-1.html5）停业务或查杀查杀方法：https://bbs.huaweicloud.com/forum/thread-147712-1-1.html6）业务整改和调优针对单个业务导致的资源高，处理方法主要为SQL调优。针对批量业务导致的资源高，处理方法主要为SQL调优或限并发（前提SQL已最优）。2、网络慢通信是分布式场景下的基础建设，承担着各节点数据交互的使命，通信效率的高低会极大影响着查询等各类业务性能的好坏。网络慢大多体现在以下两点：1）客户端连接满、连接慢处理案例：https://bbs.huaweicloud.com/blogs/2394712）集群内节点建连慢、数据交互慢计划中Gather、Redistribute、Broadcast等通信算子耗时高等待视图中create conn、wait pooler等状态持续时间长通信性能问题处理方法及案例：https://bbs.huaweicloud.com/blogs/248843小结触发数据库性能问题的因素本就种类繁多，而在分布式场景更是这样，任何一个节点、环节、链路出现问题和瓶颈，都会因短板效应影响整个集群的性能，因此快速识别短板（阻塞点）、瓶颈点（系统资源）就成为关键，而前面说的三个阶段也是围绕这两个点进行。当然，也并不是所有场景都需要严格按照一二三的顺序来排查，可以根据实际情况调整排查顺序并且可能需要来回校验来互相印证，希望大家能灵活运用。引用自博文链接：https://bbs.huaweicloud.com/blogs/297384

select 'execute direct on('||coorname||') ''select pg_terminate_backend('||pid||')'';', sysdate - query_start as dur, substr(query, 1, 60) from pgxc_stat_activity where usename <> 'omm' and state = 'active' -- query like '%xxxx%' order by dur desc limit 30;该语句可拼接出查杀语句，可以将结果保存到文件中一起执行。过滤条件可以根据需要调整：

本文所述接口部分为后台命令接口，对公有云形态无法使用。下文出自《内核产品文档》。逻辑解码概述功能描述GaussDB DWS中提供了逻辑解码功能，通过反解xlog的方式生成逻辑日志。目标数据库解析逻辑日志以实时进行数据复制。具体如图1所示。逻辑复制降低了对目标数据库的形态限制，支持异构数据库、同构异形数据库对数据的同步，支持目标库进行数据同步期间的数据可读写，数据同步时延低。逻辑复制由两部分组成：逻辑解码和数据复制。逻辑解码会输出以事务为单位组织的逻辑日志。业务或数据库中间件将会对逻辑日志进行解析并最终实现数据复制。GaussDB 200GaussDB 300ElkDWS当前只提供逻辑解码功能，因此本章节只涉及逻辑解码的说明。逻辑解码为逻辑复制提供事务解码的基础能力，GaussDB DWS提供了两种解码方式：使用SQL函数接口进行逻辑解码。此方法调用方便，不需使用工具，对接外部工具接口也比较清晰，不需要额外适配。使用SQL函数接口进行逻辑解码。此方法调用方便，不需使用工具，对接外部工具接口也比较清晰，不需要额外适配。使用流复制方式进行逻辑解码。该方法需要通过pg_recvlogical工具实现。使用该方式进行解码相比于SQL方式，可以解决大事务解码撑爆内存问题，并在高并发或长事务场景下有效提升解码效率。由于逻辑日志是以事务为单位的，在事务提交后才能输出，且逻辑解码是由用户驱动的；因此为了防止事务开始时的xlog被系统回收，或所需的事务信息被VACUUM回收，GaussDB DWS新增了逻辑复制槽，用于阻塞xlog的回收。一个逻辑复制槽表示一个更改流，这些更改可以在其它集群上以它们在原集群上产生的顺序被重播。逻辑复制槽，由每个逻辑日志的获取者维护一个。注意事项不支持DDL语句解码。不支持列存、数据页复制的解码。不支持解码分布式事务，当前机制为从DN解码，无法保证分布式事务一致性解码。当执行DDL语句（如alter table）后，该DDL语句前尚未解码的物理日志可能会丢失。使用逻辑解码功能时，禁止进行集群在线扩容。单条元组大小不超过1GB，考虑解码结果可能大于插入数据，因此建议单条元组大小不超过500MB。不支持压缩表的DML语句解码。GaussDB 200GaussDB 300ElkDWS支持解码的数据类型为：INTEGER、BIGINT、SMALLILNT、TINYINT、SERIAL、SMALLSERIAL、BIGSERIAL、FLOAT、DOUBLE PRECISION、DATE、TIME[WITHOUT TIME ZONE]、TIMESTAMP[WITHOUT TIME ZONE]、CHAR(n)、VARCHAR(n)、TEXT。使用SQL函数接口进行逻辑解码GaussDB DWS可以通过调用SQL函数，进行创建、删除、推进逻辑复制槽，获取解码后的事务日志。前提条件设置GUC参数wal_level=logical。设置GUC参数max_replication_slots>每个DN所需的（物理流复制槽数+逻辑复制槽数）。物理流复制槽提供了一种自动化的方法来确保主DN在所有备DN或从备DN收到xlog之前，xlog不会被移除。也就是说物理流复制槽用于支撑集群HA。集群所需要的物理流复制槽数为：一组DN中，备加从备的和与主DN之间的比例。例如，假设集群的DN高可用方案为1主、1备、1从备，则所需物理流复制槽数为2。又例如，假设集群的DN高可用方案为1主3备，则所需物理流复制槽数为3。关于逻辑复制槽数，请按如下规则考虑。一个逻辑复制槽只能解码一个Database的修改，如果需要解码多个Database，则需要创建多个逻辑复制槽。如果需要多路逻辑复制同步给多个目标数据库，在源端数据库需要创建多个逻辑复制槽，每个逻辑复制槽对应一条逻辑复制链路。用户需要通过DN端口连接数据库，才可以直接使用SQL函数接口进行逻辑解码操作。如果使用CN端口连接数据库，则需要通过EXECUTE DIRECT ON (datanode_name) 'statement'语句来执行SQL函数。仅限数据库管理员和拥有REPLICATION权限的用户进行操作。操作步骤以操作系统用户omm登录安装有MPPDB服务Elk服务DWS集群GaussDB300服务的任一主机。执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。执行如下命令登录数据库。gsql -d postgres -p 25308251088000 -r执行如下命令查询DN所在节点名称。1postgres=#SELECT * FROM pgxc_node WHERE node_type = 'D'; 返回信息如下，其中node_name字段下dn_xxxx_xxxx为DN名称。本例中DN名称为：dn_6001_6002、dn_6003_6004、dn_6005_6006。node_name | node_type | node_port | node_host | node_port1 | node_host1 | hostis_primary | nodeis_primary | nodeis_preferred | node_id | sctp_port | control_port | sctp_port1 | control_por t1 | nodeis_central --------------+-----------+-----------+----------------+------------+----------------+----------------+----------------+------------------+-------------+-----------+--------------+------------+------------ ---+---------------- dn_6003_6004 | D | 40000 | 10.180.157.130 | 45000 | 10.180.155.74 | t | f | f | -966646068 | 40002 | 40003 | 45002 | 450 03 | f dn_6005_6006 | D | 40000 | 10.180.155.74 | 45000 | 10.146.187.231 | t | f | f | 868850011 | 40002 | 40003 | 45002 | 450 03 | f dn_6001_6002 | D | 40000 | 10.146.187.231 | 45000 | 10.180.157.130 | t | f | f | 1644780306 | 40002 | 40003 | 45002 | 450 03 | f (3 rows)执行如下命令退出数据库。1\q 创建逻辑复制槽。创建批量创建逻辑复制槽脚本create_slot.sql。1vim create_slot.sql 脚本示例如下，每一条SQL语句代表在dn_xxxx_xxxx上创建名称为slot1的逻辑复制槽。此处以在3查询到的DN上建立逻辑复制槽为例，用户可以根据实际查询的DN情况对SQL语句进行增加或删除。1 2 3EXECUTE DIRECT ON (dn_6001_6002) 'SELECT * FROM pg_create_logical_replication_slot(''slot1'', ''mppdb_decoding'')'; EXECUTE DIRECT ON (dn_6003_6004) 'SELECT * FROM pg_create_logical_replication_slot(''slot1'', ''mppdb_decoding'')'; EXECUTE DIRECT ON (dn_6005_6006) 'SELECT * FROM pg_create_logical_replication_slot(''slot1'', ''mppdb_decoding'')'; 其中，dn_xxxx_xxxx表示DN名称，slot1表示创建的逻辑复制槽名称，用户可以根据实际情况替换。mppdb_decoding为插件名称，目前仅支持该插件。关于创建逻辑复制槽的SQL函数，详细请参见pg_create_logical_replic...。执行如下语句运行脚本。gsql -d postgres -p 25308251088000 -f /home/omm/create_slot.sql -L create_slot_log其中，-f指定读取的文件，-L为可选参数，指定后将所有查询输出记录到指定文件create_slot_log中。参见2登录数据库。在数据库中创建表t_2,并插入数据后退出数据库。1 2postgres=# CREATE TABLE t_2(a int PRIMARY KEY, b int); postgres=# INSERT INTO t_2 VALUES(1,1),(2,2),(3,3),(4,4),(5,5); 读取逻辑复制槽的解码结果。创建批量读取逻辑复制槽的解码结果脚本read_slot.sql。1vim create_slot.sql 脚本示例如下，每一条SQL语句代表读取在dn_xxxx_xxxx上名为slot1的逻辑复制槽的解码结果。用户可以根据实际查询的DN情况对SQL语句进行增加或删除。1 2 3EXECUTE DIRECT ON (dn_6001_6002) 'SELECT * FROM pg_logical_slot_peek_changes(''slot1'', NULL, 4096)'; EXECUTE DIRECT ON (dn_6003_6004) 'SELECT * FROM pg_logical_slot_peek_changes(''slot1'', NULL, 4096)'; EXECUTE DIRECT ON (dn_6005_6006) 'SELECT * FROM pg_logical_slot_peek_changes(''slot1'', NULL, 4096)'; 其中，dn_xxxx_xxxx表示DN名称，slot1表示读取的逻辑复制槽名称，NULL表示对解码的截止位置无限制，4096表示解码不超过4096条记录。用户可以根据实际情况替换。关于读取逻辑复制槽的SQL函数，详细请参见pg_logical_slot_peek_cha...。执行如下语句运行脚本。gsql -d postgres -p 25308251088000 -f /home/omm/read_slot.sql -L read_slot_log删除逻辑复制槽。创建批量删除逻辑复制槽脚本drop_slot.sql。1vim drop_slot.sql 脚本示例如下，每一条SQL语句代表删除在dn_xxxx_xxxx上名为slot1的逻辑复制槽。用户可以根据实际查询的DN情况对SQL语句进行增加或删除。1 2 3EXECUTE DIRECT ON (dn_6001_6002) 'SELECT * FROM pg_drop_replication_slot(''slot1'')'; EXECUTE DIRECT ON (dn_6003_6004) 'SELECT * FROM pg_drop_replication_slot(''slot1'')'; EXECUTE DIRECT ON (dn_6005_6006) 'SELECT * FROM pg_drop_replication_slot(''slot1'')'; 其中，dn_xxxx_xxxx表示DN名称，slot1表示要删除的逻辑复制槽名称，用户可以根据实际情况替换。关于删除逻辑复制槽的SQL函数，详细请参见pg_drop_replication_slot。执行如下语句运行脚本。gsql -d postgres -p 25308251088000 -f /home/omm/drop_slot.sql -L drop_slot_log操作步骤以操作系统用户omm登录安装有MPPDB服务Elk服务DWS集群GaussDB300服务的任一主机。执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。使用如下命令通过DN端口连接默认数据库postgres。gsql -d postgres -p 40000 -r其中，40000为数据库DN端口号，用户可根据实际情况替换。复制槽是建立在DN上的，因此需要通过DN端口连接数据库。创建名称为slot1的逻辑复制槽。1 2 3 4 5postgres=# SELECT * FROM pg_create_logical_replication_slot('slot1', 'mppdb_decoding'); slotname | xlog_position ----------+--------------- slot1 | 0/2A33AD8 (1 row) 在数据库中创建表t，并向表t中插入数据。1 2postgres=# CREATE TABLE t(a int PRIMARY KEY, b int); postgres=# INSERT INTO t VALUES(3,3); 读取复制槽slot1解码结果，解码条数为4096。1 2 3 4 5 6 7 8 9postgres=# SELECT * FROM pg_logical_slot_peek_changes('slot1', NULL, 4096); location | xid | data -----------+-------+------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------- 0/2A33F00 | 16037 | BEGIN 16037 0/2A33F00 | 16037 | {"table_name":"public.t","op_type":"INSERT","columns_name":["a","b"],"columns_type":["integer","integer"],"columns_val":["3","3"],"old_keys_name ":[],"old_keys_type":[],"old_keys_val":[]} 0/2A34248 | 16037 | COMMIT 16037 (3 rows) 删除逻辑复制槽slot1。1 2 3 4 5postgres=# SELECT * FROM pg_drop_replication_slot('slot1'); pg_drop_replication_slot -------------------------- (1 row) 使用流复制方式进行逻辑解码流复制方式是通过pg_recvlogical工具实现的，pg_recvlogical工具通过连接指定的DN端口，创建、删除逻辑复制槽以及持续、实时的从该DN获取逻辑解码中间结果，输出到文件或标准输出。pg_recvlogical工具连接DN后，DN会建立一个常驻的WalReceiver线程，持续不断的解码物理日志生成逻辑日志，并发送给pg_recvlogical进程。操作步骤以下步骤需要在每个DN节点上执行。以操作系统用户omm登录安装有MPPDB服务Elk服务DWS集群GaussDB300服务的任一主机。执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。创建逻辑复制槽。pg_recvlogical -d postgres -S test_slot -p 35779 --create其中，postgres为连接的数据库名称，test_slot为创建的逻辑复制槽名称，35779为数据库DN端口号，用户可根据实际情况替换。复制槽是建立在DN上的，因此需要通过DN端口连接数据库。使用如下命令登录数据库。gsql -d postgres -p 25308251088000 -r在数据库中创建表t_1,并向表中插入数据。1 2postgres=# CREATE TABLE t_1(a int PRIMARY KEY, b int); postgres=# INSERT INTO t_1 VALUES(3,3); 执行如下命令退出数据库。1\q 开启流式解码，结果输出到stdout。pg_recvlogical -d postgres -S test_slot -p 35779 --start -v -f - pg_recvlogical: starting log streaming at 0/0 (slot test_slot) pg_recvlogical: initiated streaming pg_recvlogical: confirming write up to 0/0, flush to 0/0 (slot test_slot) pg_recvlogical: confirming write up to 0/2A342E8, flush to 0/2A342E8 (slot test_slot) pg_recvlogical: confirming write up to 0/2A34320, flush to 0/2A34320 (slot test_slot) pg_recvlogical: confirming write up to 0/2A34320, flush to 0/2A34320 (slot test_slot) BEGIN 16039 table public.t: INSERT: a[integer]:4 b[integer]:4 COMMIT 16039 pg_recvlogical: confirming write up to 0/2A34450, flush to 0/2A34450 (slot test_slot) pg_recvlogical: confirming write up to 0/2A34450, flush to 0/2A34450 (slot test_slot)删除逻辑复制槽。pg_recvlogical -d postgres -S test_slot -p 35779 --drop上述命令中，postgres为连接的目标数据库名，test_slot为创建的逻辑复制槽名称，35779为数据库的DN端口号。有关pg_recvlogical工具详细信息，请参见pg_recvlogical。注意事项使用pg_recvlogical工具前，需要确保pg_hba.conf文件中允许该主机以及用户进行复制连接操作。如果不允许，会报如下错误：pg_recvlogical: could not connect to server: FATAL: dn_6001_6002: no pg_hba.conf entry for replication connection from host "[local]", user "omm", SSL off解决办法：查看当前DN数据目录下的pg_hba.conf文件，将关于复制连接的相关信息改为非注释状态，修改后的样例如下所示。#Allow replication connections from localhost, by a user with the # replication privilege. local replication omm trust host replication omm 127.0.0.1/32 trust host replication omm ::1/128 trust

请问什么字段会是分布列

1、数据库连接的创建、释放连接的频繁操作造成资源的浪费从而影响系统的性能。2、SQL语句编写在代码中，硬编码造成代码不容易维护，实际应用中SQL语句变化的可能性比较大，一旦变动就需要改变java类。3、使用preparedStatement的时候传递参数使用占位符，也存在硬编码，因为SQL语句变化，必须修改源码。4、对结果集的解析中也存在硬编码。