摘要： 性能调优是应用迁移或开发过程中的关键步骤，同时也在整个项目实施过程中占据很大的份量，本篇主要介绍数据库级别的性能调优思路和总体策略。性能调优是应用迁移或开发过程中的关键步骤，同时也在整个项目实施过程中占据很大的份量，在很多实施步骤中都需要进行考虑，从开始的数据建模，表定义的设计，到数据库硬件、集群部署的选择，再到数据库系统级调优、数据表结构设计，以及单个SQL语句的编写及调优，都要考虑对性能的影响。同时，性能调优通常没有明确的衡量标准，没有明确的对错之分，通常需要的隐式技能比较多，使得其的技术含金量得以提升。通常来看，要做到一个性能调优的高手，除了对于应用程序的逻辑做到游刃有余外，还需要对应用的数据库的基本实现原理有所了解，更甚者，还需要对操作系统、网络等基础知识有所涉猎，同时还要具备性能诊断和分析技巧。当然，性能调优是一个不断积累的过程，大家不用考虑一步到位，唯有进行实践的积累，才能在广阔的调优战场所向披靡。本篇博文作为《GaussDB(DWS)性能调优系列》的专题文章，主要介绍数据库级别的性能调优思路和总体策略，包括系统级和语句级调优。同时，《GaussDB(DWS)性能调优系列》文章分为基础篇和实战篇，各位读者在通过基础篇文章了解数据库的基本原理后，可以结合调优思路，对实战篇的各个调优技巧进行深入的学习。有关整个调优过程中的其它方面，后续论坛会推出其它博文进行介绍。1. GaussDB DWS执行架构及说明GaussDB DWS是典型的share-nothing架构，其计算组件的示意图如上图所示，主要由CN（Coordinator）和DN（DataNode）组成。CN是整个集群的协调者，是整个集群与应用进行连接处理的门户，用于接收客户的SQL语句并返回执行结果。DN是集群进行数据计算的主体，各个DN拥有独立的存储和计算资源，使得各个DN可以独立地进行计算。GaussDB DWS支持多CN架构，通常应用程序会通过LVS（负载均衡设备）将语句均匀分发到各个CN上，以减少单个CN的瓶颈作用。GaussDB DWS的SQL处理流程如上方右图所示，其包含以下几个主要步骤：（1）CN通过驱动或客户端接收到一条SQL后，会进行解析、优化，并最终返回执行结果；（2）CN进行优化后，生成相应的执行计划；（3）CN将相同的执行计划下发到各个DN进行执行；（4）如果DN之间需要进行数据交换，则执行计划中包含流操作算子Stream，DN之间同步通过Stream算子进行数据交换，共同完成计划的执行并向CN返回结果。同时，GaussDB DWS对于不需要DN间数据交换的语句，还支持语句下发到DN生成计划；对于部分不支持分布式查询的语句，生成不能下推的计划（此计划对于大数据量性能较差）。各种计划的对比可详见博文《GaussDB(DWS)性能调优系列基础篇三：衍化至繁之分布式计划详解》。本文后续的讨论均基于Stream计划。2. 整体调优思路通过前面对SQL语句执行流程的介绍，我们可以知道，性能瓶颈可能发生在CN端、DN端，以及结果集返回，驱动数据处理等环节，性能调优的第一步就是定位瓶颈点主要发生在哪个环节。由于GaussDB DWS大数据量处理时，大部分执行时间消耗在DN端，故本博文主要针对DN端语句执行进行总体调优思路的分享。谈到执行性能，其实从数据模型建模、集群部署、表结构设计，到最终的SQL语句优化，都与之紧密相关，如上图所示，我们使用金字塔来描述整个调优过程。越接近塔尖，其对于整个业务性的影响范围越广，需要调优时，调优成本也越高，所以在设计之初需要投入足够精力，从上至下，我们需要全面的设计，才能减少在最终SQL调优时返工的可能。整个调优过程其实是一个不断迭代的过程，如上图所示。即使设计再严密，也有可能出现SQL语句性能的优化需要导致数据建模更改、集群部署、表分布键调整的情况，这时一发动全身将引起较高的成本，同时会对其它已经调优完毕的SQL产生影响，导致重新调优，成本较高。我们统一将前三阶段归结为静态调优，将SQL语句级调优归结为执行态调优。下面重点来探讨执行态调优-SQL语句调优，从调优步骤来看可以分为性能瓶颈诊断、性能原因分析和调优项实施，从调优实施对象来看，可能包括前面提到的数据建模、集群部署、表结构设计方面的修改，SQL语句层调优可以分为系统级调优和语句级调优。当然，有一些调优项，例如系统调优项，可以作为经验固化下来，在集群部署的时候就一并设置好，减少这方面调优花费的成本。同时，SQL调优也是一个迭代的过程，在实施一次调优项后，需要继续重新进行调优分析，直至性能达到标准为止。后面的章节，将围绕调优步骤和SQL层的调优项来开展。3. 性能瓶颈诊断GaussDB DWS提供了丰富的计划信息显示工具Explain，以及动态执行信息分析工具Top SQL。Explain工具主要针对单个语句进行展示，可以使用explain命令显示CN生成的SQL语句的计划，也可以使用explain analyze/performance命令显示执行态信息。通过执行态信息，我们可以分析出算子为单位的性能，也可以分析出算子内部各步骤的性能，进一步为诊断性能的瓶颈打下了基础。Explain工具相关内容请参考博文《GaussDB(DWS)性能调优系列基础篇二：大道至简explain计划信息》。Top SQL工具则针对集群中运行的语句进行整体性能分析，其包含12个视图，可以将执行时间超过一定设置阈值的语句的执行状态、执行结果进行实时查询，同时可以设置将其转储用作后续分析。附加于该工具之上的SQL自诊断调优工具，则通过瓶颈点的分析，给出可能的性能原因分析。同时，我们还提供Unique SQL工具，进行一类SQL的性能持续跟踪，可以用于发现系统资源及硬件问题对SQL性能产生的影响。Top SQL工具相关内容请参考博文《GaussDB(DWS)性能调优系列实战篇二：十八般武艺之坏味道SQL识别》。4. 性能原因分析性能原因分析属于性能调优里的高阶知识了，通常要对数据库的执行实现原理有基本了解才能够逐步深入下去。本章节将深入浅出地介绍数据库执行实现原理的基本技术，帮助各位读者朋友能够有兴趣去主动查找性能产生的原因，从而自己找到性能调优的方法。前面已经对GaussDB DWS的执行流程进行了介绍，由CN生成执行计划下发到DN去执行。GaussDB DWS是基于代价来生成计划的，因此需要依据基表的统计信息，进行每一步结果集统计信息的估算，根据数据规模的场景从GaussDB DWS支持的备选算子中选择最优的算子组合成计划进行执行。因此，统计信息是计划准确的前提，在执行SQL语句前要确保收集最新的统计信息，有关统计信息的收集可以参见博文《GaussDB(DWS)性能调优系列基础篇一：万物之始analyze统计信息》。由于统计信息只包含基表的统计信息，表关联之后的统计信息只能通过估算得到，因此仍然可能存在估算不准的情况。GaussDB DWS针对不同的SQL语句中的操作，为每个操作内部实现了不同的算子。每个算子可能在部分场景下是占优的，但其它场景比较差。SQL优化时，根据具体的场景去自动匹配最优的算子。如果存在估算不准，将导致算子选择出现失误，从而计划较差，此时就需要根据计划的瓶颈来分析具体的原因了。通常情况下，GaussDB处理的操作类型主要分为：扫描算子（Scan）、关联算子（Join）、聚集算子（Agg）和网络传输算子（Stream）。下表列出了各算子类别的使用场景，以及各类别中可选的算子，及其适用范围，同时列出调优场景，供大家参考。（1）扫描算子（Scan）：主要用于处理从存储扫描数据，返回上层算子，包括：全表扫描算子、索引扫描算子，其中行列存均对应不同的全套扫描算子，索引扫描包括：IndexScan（普通索引扫描）、IndexOnlyScan（仅扫描索引即可获得结果）、BitmapScan（需要索引扫描获取位图后再到基表上扫描），BitmapScanAnd/Or（从多个索引扫描进行位图运算后再到基表上扫描），由于索引扫描的原理基本都相同，故一并探讨。（2）关联算子（Join）：主要用于处理表的关联操作。在数据库中，多表关联时，SQL优化会选择关联顺序进行两两关联。表关联时可以包含关联操作，也可以没有关联操作（笛卡尔积）。在GaussDB DWS中，主要包含NestLoop, HashJoin, MergeJoin三种关联算子。（3）聚集算子（Agg）：（4）网络传输算子（Stream）：（5）其它算子：同时GaussDB DWS还支持排序（Sort）、集合（SetOp）、物化（Materialize）、窗口聚集（WindowAgg）和输出限制（Limit）算子，由于调优基本不涉及，故此处略过。5. 调优项实施在知道导致性能问题的原因后，就可以制定调优项并开始实施了。前面已经提到，调优项实施的范围很广。本博文仅探讨数据库级的调优项，包括系统级调优和语句级调优两部分。a)系统级调优项系统级调优又细分为操作系统参数调优和数据库全局参数调优，通常涉及到的是系统CPU、IO、内存、网络资源的充分使用，避免资源冲突，提升整个系统查询的吞吐量。由于数据库是运行在操作系统之上的，因此操作系统资源的利用率对于数据库性能的提升起到基石的作用。对于操作系统参数的调优，主要集中在操作系统内存参数、IO参数以及网络参数的设置上，具体可参见GaussDB DWS产品文档。数据库级别的调优，主要也是集中在上述资源的使用上，在上述四维度有以下主要因素的考虑（具体设置方法可以参见GaussDB DWS产品文档）：b)语句级调优项语句级调优通常需要通过计划分析，找到性能瓶颈点，然后根据瓶颈点对应的扫描、关联、聚集、Stream等算子，分析是否属于算子适用场景，是否符合调优条件。如果是，我们有以下调优手段：i. 通过修改表定义，包括行列存、表的分布方式，达到减少IO和网络资源开销的目的，详见博文《GaussDB(DWS)性能调优系列实战篇三：十八般武艺之好味道表定义》。ii. 如果最终分析是由于估算不准导致，可以通过相关GUC参数调整来设置不同的结果集估算模型，或禁止生成某种类型的算子，通过改进估算值达到优化计划的目的，详见博文《GaussDB(DWS)性能调优系列实战篇五：十八般武艺之路径干预》。iii.如果在迁移或升级过程中出现计划劣化，也可以通过Plan Hint的调优方式干预优化器生成理想的计划，详见博文《GaussDB(DWS)性能调优系列实战篇六：十八般武艺Plan hint运用》。iv.对于上述调优手段都无法解决的问题，例如：下推问题，相关子查询提升，NOT IN等问题，或者SQL语句存在计算冗余等问题，需要根据瓶颈点选择灵活多变的SQL改写策略消除瓶颈点，具体可参见博文《GaussDB(DWS)性能调优系列实战篇四：十八般武艺之SQL改写》总的来说，性能调优是一项艰巨的工程，当然深入其中，学习到的知识以及获得的收获都是非常大的。后续论坛也会推出更多的博文对性能调优的方方面面进行介绍，帮助各位读者迅速积累调优的经验

前言GaussDB(DWS)是企业级的大规模并行处理关系型数据库，采用MPP(Massive Parallel Processing)架构，支持PB级别数据量的处理能力，适用于详单查询、数据仓库、混合负载和大数据分析场景。表结构设计是数据库建模的一个关键环节，表定义好坏直接决定了集群的有效容量以及业务查询性能，本文从产品架构、功能实现以及业务特征的角度阐述在GaussDB(DWS)的中表定义时需要关注的关键因素。1      存储方式设计GaussDB(DWS)支持行存储(row-based storage)和列存储(column-based storage)两种存储方式，分别适用不同的业务场景。通常来讲典型的点查询为主的场景推荐使用行存储，典型的统计分析型业务推荐使用列存储。1.1      行存储行存储模式下，一条数据的所有列组合在一起称之为一个tuple，多个tuple组成一个page，所有的page构成表的数据文件。pages是行存数据存取的最小单元，一个page默认8KB。page的基本结构如下行存储模式下，所有数据列集中存储在一个tuple中，所以行存储的更新(UPDATE)、删除(DELETE)、索引点查性能较好，但是当查询列只涉及所有列的很少一部分的时候，所有列的数据也都会被读取，导致大量的无效IO，因此推荐比较简单点查场景的业务采用行存储1.2      列存储列存储下把数据表中的每一列单独存储，每个列的 6w条数据组成一个CU，每个列的所有的CU构成一个列的数据文件，每个列都会有单独的数据文件。CU的基本结构如下列数据之间具有更高的相似度，所以列存储的压缩性能更好。当只查询少量列且查询数据量较大时，列存储的IO性能收益很明显。同时因为数据分列存储，导致更新(UPDATE)、删除(DELETE)、索引点查性的时候需要访问或者刷新更多的文件，导致大量的随机IO，因此相比行存储，列存储的更新、删除、索引点查询的性能较差。列存储天然跟向量化执行引擎对接，在表关联、汇聚等重计算场景下可以使用向量化执行引擎提升计算性能，因此统计分析等重IO和重计算型业务一般推荐使用列存储。1.3      表存储方式选择表的存储类型是表定义设计的第一步，客户业务属性是表的存储类型的决定性因素。根据以上我们对行存储和列存储原理的介绍，重查询分析(大量的多表关联、group by操作)场景推荐使用使用列存表，典型的有数仓场景；以点查询为主的场景推荐使用行存表，典型的有详单查询场景。存储类型适用场景行存点查询(返回记录少，基于索引的简单查询)增删改比较多的场景列存统计分析类查询 (多表关联+group by操作)即席查询 （查询条件列不确定，无法明确索引）GaussDB(DWS)支持单个database中同时存储行存储和列存储类型的表，以更好的支持混合负载场景1.4      表存储方式定义表的行/列存储通过表定义的orientation属性定义。当指定orientation属性为row时，表为行存储；当指定orientation属性为column时，表为列存储；如果不指定，默认为行存储。行存表定义方式如下：CREATE TABLE storage (     c_id int,     c_d_id int NOT NULL,     c_w_id int NOT NULL,     c_first varchar(16) NOT NULL )WITH(orientation=row) DISTRIBUTE BY HASH(c_d_id);列存储表定义方式如下：CREATE TABLE storage (     c_id int,     c_d_id int NOT NULL,     c_w_id int NOT NULL,     c_first varchar(16) NOT NULL )WITH(orientation=column) DISTRIBUTE BY HASH(c_d_id);2      分布方式设计GaussDB(DWS)的MPP架构，天然支持通过散列的方式进行水平分表，将业务数据表的元组打散存储到各个数据节点(DataNode)上，这样可以并行利用各个数据节点的IO能力提升数据扫描的效率。为了优化高频关联小表的查询性能，GuassDB(DWS)也支持复制的数据分布方式。表的分布方式取决于表的业务属性，事实表一般数据量较大，且数据增加或者变化很频繁，建议使用散列分布；维度表数据量较小，且数据一般不会变化，一般只有定期更新操作，建议使用复制分布。2.1      散列分布散列分布是按照某种散列规则，把表数据map到指定的数据节点(DataNode)上进行存储的方式。散列分布可以利用各个节点的IO资源，提升各个数据节点的IO能力。GaussDB(DWS)中采用hash的散列策略，按照表定义时指定的hash列组合，对一条记录的某一个或几个字段进行hash运算后，生成对应的hash值，根据DN实例与哈希值的映射关系获得该元组的目标存储位置。对于散列分布的表，hash分布列的选择非常重要。当hash分布列选择合理时，Hash散列策略可以大大减小计算节点之间的数据交互，大幅提升查询性能；但是当hash分布列选择不合理时，会导致数据倾斜(某个或者某些DataNode的数据量严重超过其它DataNode的数据量)，因为短板效应导致集群的有效容量下降。散列主要使用于客户业务表，这些表有数据量大、数据量逐渐增加的特征，适用散列分布可以有效的提升表查询性能。2.2      复制分布复制分布(replication)策略将表中的全量数据在集群的每一个DN实例上保留一份。在关联操作中复制表可以避免数据重分布操作，减小网络开销，同时减少了plan segment(每个plan segment都会起对应的线程)的个数；但是复制分布策略会导致比较严重的数据冗余，因此只有小表才适合复制分布策略。 实际生产上只有小数据量、查询频繁、更新(DELETE/INSERT/UFPATE)很少的表(基本都是维度表)才会定义replication分布策略2.3      分布方式选择表数据分布方式主要依据表的业务属性和数据属性决定，简单总结如下策略适用场景hash数据量较大的事实表replication数据量小、查询频繁、更新(DELETE/INSERT/UFPATE)很少的维度表2.4      分布列定义表的复制分布属性可以通过表定义指定：CREATE TABLE storage (     c_id int,     c_d_id int NOT NULL,     c_w_id int NOT NULL,     c_first varchar(16) NOT NULL )WITH(orientation=row) DISTRIBUTE BY REPLICATRRION; 表的散列分分布属性可以通过表定义：CREATE TABLE storage (     c_id int,     c_d_id int NOT NULL,     c_w_id int NOT NULL,     c_first varchar(16) NOT NULL )WITH(orientation=row) DISTRIBUTE BY HASH(c_d_id);3      分布列设计对于采取散列分布策略的表，分布列的选择取决于表数据的特征以及表相关的业务查询特征，推荐使用经常做关联查询的列、且数据分布均匀的列作为分布列。好的分布列可以通过减少跨节点的数据计划节省网络资源开销，优化查询性能。3.1      分布列选择策略Hash分布表的分布列选取至关重要，需要满足以下原则：a)  列值应比较离散，以便数据能够均匀分布到各个DN分布列值分布不均匀会导致数据在数据节点分布不均匀(某些DataNode上数据量大，某些DataNode上数据量小)，这会导致不同DataNode上数据扫面的计算量不均衡，从而拖慢整个表扫描的性能；同时会因为部分DataNode的磁盘容量提前爆满，集群只读，导致集群有效容量下降。通常情况下使用表的主键列或者唯一索引列作为表的分布列是一个不错的选择b)  考虑选择查询中的连接条件为分布列GaussDB(DWS)的散列策略是hash，根据GaussDB(DWS)的分布式查询框架，当两表等值关联(join)列刚好是表的分布列时(如果分布列是多列，那么要求所有列都存在等值关联条件)，join任务可以不再数据重分布的情况下直接Join，这样可以省去数据重分布的时间开销和网络资源开销，从而提升查询计算性能。c)  在满足前面两条原则的情况下尽量不要选取存在常量等值filter的列GaussDB(DWS)会协调节点(Coordinator)上进行任务规划，此时会根据表的过滤条件(Filter)进行扫面操作剪枝优化，以较小IO资源开销。如果表dwcjk的分布列是zqdh，且表dwcjk扫描时存在Filter条件zqdh=’000001’，而根据散列策略zqdh=’000001’的值都分布在数据节点DN1上，那么协调节点(Coordinator)上进行任务规划时会对dwcjk表的扫描操作进行剪枝(指定只有在数据节点DN1对表dwcjk进行数据扫描操作)。这样对于表扫描的实际压力会值落在节点DN1，导致不同数据节点的IO压力不均衡。注意此策略主要适用于统计分析类的重查询场景，对于详单查询等以点查为主要场景的查询类业务，在满足前两个约束的前提下，可以优选存在常量等值Filter约束列作为分布列。因为这种场景在数据节点上使用索引加速查询，查询耗时往往以ms或者几十ms计，通过剪枝把查询任务map到具体的某个数据节点上执行，节省无效操作(不用连接到所有的数据节点上操作)，同时也会大大的提高并发能力3.2      分布列选择的限制GaussDB(DWS)的列存储格式的表不支持主键和唯一约束，行存储格式表支持主键和唯一约束。但是存储格式表的主键和唯一约束的创建存在严格约束：分布列的集合是主键列或者索引列的子集。 多个列作为分布列时，分布列的顺序会影响数据分布，即同一条记录在distribute by hash(col1, col2)方式下，跟在distribute by hash(col2, col1)分布方式下可能会map到不同的DataNode上进行存储。GaussDB(DWS)对分布列的个数没有限制，但是建议分布列的个数尽量少，一方面可以减小数据map到不同DN的计算开销，同时也可以更好的全匹配join条件，提升查询性能。3.3      分布列离散性校验对于当前已创建并且导入数据的表，可以使用如下SQL检验表数据分布的离散型-- 'public'是表的schema名称，'storage'是表名 SELECT * FROM table_distribution('public.storage') ORDER BY dnsize; 对于已经创建并且导入数据的表，如果我们认为当前的分布列不够离散，在修改为其它列之前，可尝试使用如下SQL判断目标分布列的离散性-- 'public'是表的schema名称，'storage'是表名，c_id是要检测的列名 SELECT * FROM table_skewness('public.storage', 'c_id') ORDER BY seqnum; 当确定目标分布列之后，可以使用如下SQL实现分布列的修改-- 'public'是表的schema名称，'storage'是表名，c_id是修改后的目标分布列 ALTER TABLE public.storage DISTRIBUTE BY HASH(c_id);4      表分区设计通俗的讲表，分区就是把一个大表按照条件分割为若干个小表，这种分割体现在数据库内部的数据管理上，对表数据的常规操作(UPDATE/DELETE/INSERT/SELECT)是透明的。一般对数据和查询都有明显区间段特征的表使用分区策略可通过较小不必要的数据扫描，从而提升查询性能 4.1      分区表的优势分区表把逻辑上的一张表根据范围分区策略分成几张物理块库进行存储，这张逻辑上的表称之为分区表，物理块称之为分区。分区表是一张逻辑表，不存储数据，数据实际是存储在分区上的。分区表和普通表相比具有以下优点：a)  改善查询性能对分区对象的查询可以仅搜索自己关心的分区，提高检索效率b)  增强可用性如果分区表的某个分区出现故障，表在其他分区的数据仍然可用c)  提升可维护性对于需要周期性删除的过期历史数据，可以通过drop/truncate分区的方式快速高效处理4.2      分区策略选择当表有以下特征时，可以考虑使用表分区策略a) 数据具有明显区间性的字段分区表需要根据有明显区间性字段进行表分区。通常我们比如日期、区域、数值等字段进行分区，时间字段是最常见的分区字段。b) 业务查询有明显的区间范围特征查询数据可落到区间范围指定的分区内，这样才能通过分区剪枝，只扫描查询需要的分区，从而提升数据扫描效率，降低数据扫描的IO开销。c) 表数据量比较大小表扫描本身耗时不大，分区表的性能收益不明显，因此只建议对大表采取分区策略。列存储模式下因为每个列是单独的文件出处，且最小的存储单元CU可存储6w行数据，因此对于列存分区表，建议每个分区的数据不小于DN个数*6w4.3      分区表定义分区表策略定义分为两种方式 a)   简单区间切割这种是最常见的通用的分区定义策略，适合所有的分区定义场景。CREATE TABLE web_returns_p1 (     wr_returned_date_sk       integer,     wr_returned_time_sk       integer,     wr_item_sk                integer NOT NULL,     wr_refunded_customer_sk   integer ) WITH (orientation = column) DISTRIBUTE BY HASH (wr_item_sk) PARTITION BY RANGE(wr_returned_date_sk) (     PARTITION p2016 VALUES LESS THAN(20161231),     PARTITION p2017 VALUES LESS THAN(20171231),     PARTITION p2018 VALUES LESS THAN(20181231),     PARTITION p2019 VALUES LESS THAN(20191231),     PARTITION pxxxx VALUES LESS THAN(maxvalue) );b)    指定策略切割此方式适用于分区间隔固定、批量创建分区的场景。当分区个数很多时，此方式可大大节省创建分区的工作量CREATE TABLE web_returns_p1 (     wr_returned_date_sk       integer,     wr_returned_time_sk       integer,     wr_item_sk                integer NOT NULL,     wr_refunded_customer_sk   integer ) WITH (orientation = column) DISTRIBUTE BY HASH (wr_item_sk) PARTITION BY RANGE(wr_returned_date_sk) (     PARTITION p2016 START(20161231) END(20191231) EVERY(10000),     PARTITION p0 END(maxvalue) );4.4      分区键选择限制类似表分布列的选择，对于行存储格式的表，如果表存在主键或者唯一约束，分区键应当是是主键列或者唯一约束的索引列的子集。4.5      分区表查询只有查询语句可以进行分区剪枝的时候，分区表查询才会产生数据扫描上的性能收益。一般只有当分区键跟常量值存在直接的比较(>、<、=、<=、>=)操作时，分区表才可以正常剪枝。我们可以通过对查询语句执行explain命令查看分区剪枝的效果 有时我们期望编写的SQL语句可以进行分区剪枝，但是实际上并没有走到分区剪枝，这种预期外的行为往往是因为以下因素导致a)  分区键上有函数当分区键上存在函数调用时，分区表无法剪枝b)  分区键字段的存在隐式类型转换这种场景往往是因为分区键跟常量值的数据类型不一致，导致计划规划时分区键的数据类型发生隐式类型转换，导致分区无法剪枝5      字段设计表字段设计时需要注意以下内容a)   使用执行效率比较高的数据类型一般来说整型数据的运算(包括=、＞、＜、≧、≦、≠等常规的比较运算，以及group by等运算)效率比字符串、浮点数要高。能使用整型的场景尽量使用整型。b)  使用短字段的数据类型长度较短的数据类型不仅可以减小数据文件的大小，提升IO性能；同时也可以减小计算相关计算时的内存消耗，提升计算性能。比如我们需要一个整型数据，如果可以用smallint就尽量不用int，如果可以用int就尽量不用bigint。c)  关联列使用一致的数据类型表关联列尽量使用相同的数据类型。如果表关联列数据类型不同，在执行时数据库会动态地转化为相同的数据类型进行比较，这种转换会带来一定的性能开销，同时可能会因为类型转换导致表关联操作时发生数据重分布，导致额外的性能和资源开销。6      约束设计1)  非空(not null)约束明确不存在null值的字段加上not null约束。在特定场景下，优化器会对包含not null的查询语句进行自动优化，提升查询效率。2)  主键/唯一约束行存储表支持唯一/主键约束，如果表是散列分布，那么约束列必须包含所有的分布列；如果表做了分区，那么约束列也必须包含所有的分区列。3)  局部聚簇约束局部聚簇(partial cluster key，简称PCK)是列存储表一种局部聚簇技术，这种技术可以让表数据在批量入库的时，先对表进行局部排序，然后再写盘。这样可以让相同/相似的数据连续存储，提高数据的压缩比；同时在查询时也可以依赖列存储表的min/max稀疏索引实现表的CU过滤，从实现高效的数据过滤效果(参见《GaussDB(DWS)性能调优：列存表scan性能优化》)。一张表上只能建立一个PCK，一个PCK可以包含多列，但是一般不建议超过2列。通常我们使用经常出现的、过滤效果比较好的简单表达式中的列作为PCK列，局部聚簇约束的定义方式跟主键约束的定义方式类似CREATE TABLE web_returns_p1 (     wr_returned_date_sk       integer,     wr_returned_time_sk       integer,     wr_item_sk                integer NOT NULL,     wr_refunded_customer_sk   integer,     PARTIAL CLUSTER KEY(wr_returned_date_sk) ) WITH (orientation = column) DISTRIBUTE BY HASH (wr_item_sk);7      表定义总结最后简单总结下表定义流程

【问题描述】查看集群状态有部分实例长时间显示catchup状态【问题分析】1、连接CN查看追赶视图，发现无实例追赶2、查看实例状态的确处于catchup状态catchup结束后实例状态没能及时更新，引起集群状态有实例处于catchup状态，实际不影响业务正常运行【问题修复】登录catchup实例所在节点kill该实例后重新被拉起后状态恢复正常

【问题描述】集群当中某一主实例长时间未回收xlog积压至1.6T，引起集群只读，对端备机实例无xlog积压。【分析过程】1、连接该dn查看主备实例复制槽推进正常（811以下版本主实例分别与备机、从备建联存在两个复制槽，从备restart_lsn的值正常情况下为空，备机对应值多次查询若动态变化则说明正常推进）select * from pg_get_replication_slots();2、使用pg_controldata查看checkpoint点正常（Time of latest checkpoint为最近半个小时则为正常）3、查看cbm推进是否正常（该结果多次查询若动态变化则正常推进，超过半小时无变化则存在异常）：连接异常dn执行 select * from pg_cbm_tracked_location();4、查看该实例路径下有delay_xlog_recycle标志文件存在，若当前存在备份任务，备份结束后该文件会正常回收，否则则为异常情况按照后续修复方案修复即可。【问题修复】步骤1：在集群内部任意节点执行停止备份命令：python3 $GPHOME/script/GaussRoach.py -t stop -F步骤2：连接CN执行checkpoint等待DN回收即可:checkpoint;【机制说明】delay_xlog_recycle由Roach备份过程中产生用来延迟xlog回收以此保证备份过程中行存表的一致性点，用来恢复在备份行存文件过程中行存表发生变化的数据。

1、云数据库安全现状及问题伴随着云基础设施的快速增长和成熟，与之对应的云数据库服务也层出不穷。一方面，受益于云服务的便捷性传统企业加速业务上云，通过充分发挥云数据库特有的轻松部署、高可靠、低成本等优势降低企业运营成本，加速企业应用创新；另一方面，以苹果iCloud服务为代表的存储服务和云计算服务为移动消费者带来应用便捷性，利用云侧的数据库服务存储海量消费者的个人数据。云数据库俨然已成为数据库业务未来重要的增长点，绝大多数的传统数据库服务厂商正在加速提供更优质的云数据库服务。但无论是传统的线下数据库服务，还是日益增长的云数据库服务，数据库的核心任务都是帮助用户存储和管理数据，在复杂多样的环境下，保证数据不丢失、隐私不泄露、数据不被篡改以及服务不中断。这就要求数据库具备多层次的安全防御机制，用来抵抗来自内部和外部的恶意攻击行为。事实上，经过数据库的长期发展，已经构建了体系化的安全能力，比如通过数据库防火墙的入侵防御以及基于AI的攻击识别及智能防御，做到“攻不破”；通过在数据库服务端实现强认证机制，达到攻击者“进不来”；通过完善的权限管理模型、对象访问控制及校验机制做到恶意用户“拿不走”；通过数据加密存储机制或数据静态脱敏及动态脱敏机制实现对关键数据的保护，确保数据在被非法窃取后攻击者“看不懂”；通过多副本备份，融合区块链思想实现类账本系统能力，做到“改不了”；通过系统内部细粒度审计机制，记录用户操作行为，达到攻击行为“赖不掉”。除了传统数据库厂商本身在提升自己的能力外，许多专业化的评估测试机构也在帮助数据库厂商挖掘产品缺陷，加速完善数据库安全能力的构建，并出具专业化评估报告，作为第三方背书让用户“信得过”。这些成熟的安全技术手段，构建了数据库纵深防御的安全体系，保障数据库在应用中的安全。一个完整的防御架构如图1所示。图1：传统数据库多层级安全防御架构虽然数据库安全功能越做越强，但这些安全技术手段都是针对传统数据库所面临的威胁构建的。作为面向开放市场的云数据库服务，其所面临的风险相较于传统数据库更加多样化，更加复杂化，无论是应用程序漏洞、系统配置错误，还是恶意管理员都可能对数据安全与隐私保护造成巨大风险。云数据库，其部署网络由“私有环境”向“开放环境”转变，系统运维管理角色被拆分为业务管理员和运维管理员。业务管理员拥有业务管理的权限，属于企业业务方，而运维管理员属于云服务提供商。数据库运维管理员虽然被定义成系统运维管理，其实际依旧享有对数据的完全使用权限，通过运维管理权限或提权来访问数据甚至篡改数据；再者由于开放式的环境和网络边界的模糊化，用户数据在整个业务流程中被更充分的暴露给攻击者，无论是传输、存储、运维还是运行态，都有可能遭受来自攻击者的攻击。因此对于云数据库场景，如何解决第三方可信问题，如何更加可靠的保护数据安全相比传统数据库面临着更大挑战，其中数据安全、隐私不泄露是整个云数据库面临的首要安全挑战。当前云数据库数据安全隐私保护是针对数据所处阶段来制定保护措施的，如在数据传输阶段使用安全传输协议SSL/TLS，在数据持久化存储阶段使用透明存储加密，在返回结果阶段使用RLS(Row Level Security)或者数据脱敏策略。这些传统技术手段可以解决单点风险，但不成体系，且对处于运行或者运维状态下的数据则缺少有效的保护。面对越来越复杂的云环境，我们需要一种能够彻底解决数据全生命周期隐私保护的系统性解决方案。事实上，近年来学术界以及工业界陆续提出了许多创新思路：数据离开客户端时，在用户侧对数据进行加密，且不影响服务端的检索与计算，从而实现敏感数据保护，此时即便数据库管理员也无法接触到用户侧的密钥，进而无法获取明文数据。这一思路被称为全密态数据库解决方案，或全加密数据库解决方案。2、全密态数据库与数据全生命周期保护全密态数据库，顾名思义与大家所理解的流数据库、图数据库一样，就是专门处理密文数据的数据库系统。数据以加密形态存储在数据库服务器中，数据库支持对密文数据的检索与计算，而与查询任务相关的词法解析、语法解析、执行计划生成、事务ACID、数据存储都继承原有数据库能力。       在全密态数据库机制下，一个用户体验良好的业务数据流图如下图1所示。假定数据列c1已以密文形态存放在数据库服务端，用户发起查询任务指令。用户发起的查询任务无需进行特殊化改造，对于查询中涉及的与敏感数据c1相关联的参数，在客户端按照与数据相同的加密策略(加密算法，加密密钥等)完成加密，如图1中关联参数“123”被加密成“0xfe31da05”。参数加密完成后整个查询任务被变更成一个加密的查询任务并通过安全传输通道发到数据库服务端，由数据库服务端完成基于密文的查询检索。检索得到的结果仍然为密文，并最终返回客户端进行解密。图2：全密态数据库核心业务数据流根据该业务数据流可以看出，全密态数据库的核心思想是：用户自己持有数据加解密密钥且数据加解密过程仅在客户侧完成，数据以密文形态存在于数据库服务侧的整个生命周期过程中，并在数据库服务端完成查询运算。由于整个业务数据流在数据处理过程中都是以密文形态存在，通过全密态数据库，可以实现：(1)保护数据在云上全生命周期的隐私安全，无论数据处于何种状态，攻击者都无法从数据库服务端获取有效信息；(2)帮助云服务提供商获取第三方信任，无论是企业服务场景下的业务管理员、运维管理员，还是消费者云业务下的应用开发者，用户通过将密钥掌握在自己手上，使得高权限用户无法获取数据有效信息；(3)使能合作伙伴，通过全密态数据库可以让合作伙伴借助全密态能力更好的遵守个人隐私保护方面的法律法规。3、全密态数据库核心思路与挑战正如全密态数据库定义所描述的那样，全密态数据库的核心任务是保护数据全生命周期安全并实现基于密文数据的检索计算。在加密算法足够安全的情况下，外部攻击者及内部管理员均无法获取有效的数据信息。 对于用户来说，从已有数据库服务切换成全密态数据库或者直接将应用部署于全密态数据库，需要解决三个主要的问题：(1)如何保障密态计算机制的安全性，全密态数据库从原理上可以有效保障数据安全，但这要求密文数据检索及运算的算法在机理和工程上要达到该原理要求；(2)如何进行业务的无缝迁移或者轻量化迁移，全密态数据库最显著的特征是数据存储信息的变更，那与加密数据相关的各类参数都要同步进行变更，否则会因为计算数据形态的不对等导致查询紊乱；(3)如何避免服务切换所带来的性能损耗，本质上需要将加密算法实现和工程实现所产生的性能回退控制在一个合理的范围内，避免因为不合理的数据加解密和数据存储膨胀带来性能急速下降。只有解决这三个关键问题，才能真正的推动全密态数据库落地。目前，全密态数据库在学术界和工业界均有研究和尝试，主要聚焦于两种解决方案：(1)密码学解决方案，或称为纯软解决方案，通过设计满足密文查询属性的密码学算法来保证查询的正确性，如已知常见的OPE(Order Preserving Encryption)算法，数据加密后仍保留顺序属性;(2)硬件方案，通过可信执行环境(TEE, Trusted Execution Environment)来处理REE(Rich Execution Environment，REE与TEE相对应)环境中的密文数据运算，图3展示了ARM架构下的TEE与REE的对应关系。无论是密码学解决方案还是现有的硬件方案都有他们各自的优缺点。图3：REE与TEE逻辑关系图密码学方案的核心思路是整个运算过程都是在密文状态，通过基于数学理论的算法来直接对密文数据进行检索与计算。该方案需要解决在用户不感知的条件下，实现密文数据的安全、高效检索与计算，当前的主要挑战在两个方面：一方面学术界当前主要的密码学算法，大部分都是基于功能实现及安全能力的考虑，对于内外存储、网络吞吐、计算消耗等性能指标都会有不同的劣化，甚至有些性能完全脱离了实际场景，因此如何能在数据密文状态下实现检索和计算，并且满足性能要求，是密码学方案的最大挑战；另一方面，通常一种数学算法只能解决部分业务场景，如何将多种密码学算法融合，以实现数据库查询和计算的主要功能，也是密码学方案的一大挑战。硬件方案的核心思路是将存放于REE侧的加密数据传递给TEE侧，并在TEE侧完成数据解密和计算任务(见图3)，依赖TEE的“隔离性”或“对REE侧应用的不可见性”实现数据计算过程的安全保护。一方面，受限于TEE空间的大小（如SGX v1仅提供128MB可用空间、基于ARM TrustZone方案一般也仅提供几十MB空间），难以处理大量数据和复杂操作，这就要求TEE内仅关注关键敏感数据的查询操作，降低攻击面；另一方面由于REE与TEE运行切换和数据交互带来额外的开销，因此需要解决整个运算过程中的REE与TEE的计算资源分配与高效调度问题，也是硬件方案面临的一大挑战。4、GaussDB全密态数据库解决方案4.1 开创性自适应架构打造首款支持软模式密态计算全密态数据库中的软件方案和硬件方案目前均已取得了很多进展，特别的，工业界已开始在逐步采用硬件方案。借助诸如Intel SGX等安全硬件的TEE空间，对数据计算空间进行物理或逻辑隔离，实现数据对REE的“不可见”。但硬件方案目前存在两个较大的缺陷：首先由于数据在TEE内部均为明文存在，因此数据的安全性完全依赖于硬件本身的安全性。目前针对硬件的攻击方式如侧信道攻击等越来越多，但是一般硬件设备更新迭代周期较长，一旦出现漏洞无法及时更新修补，将直接导致用户数据长时间暴露在风险之下。其次用户在使用该特性时，密钥需要离开客户端环境发送给TEE使用，而该传输过程的安全直接依赖于硬件设备厂商的证书签名，恶意的硬件设备厂商人员完全有能力攻击并窃取用户的数据及密钥，因此硬件方案，也需要用户在使用过程中，持续信任硬件设备厂商。全密态数据库的软件方案目前在学术界发展较快，通过一系列数学算法在密文空间直接对密文进行查询运算，保障数据隐私不泄露。软件方案可以不依赖于硬件能力，也不需要在服务侧获取密钥对数据进行解密，但当前也存在着在第三章节提到的巨大挑战。图4：GaussDB全密态数据库架构在华为全连接大会上，华为正式发布基于GaussDB的全密态数据库解决方案，该方案结合软件模式与硬件模式各自的优缺点，推出融合策略，实现硬件模式和软件模式的自由切换，该方案支持全场景应用，包括公有云、混合云以及终端智慧业务，更为重要的是对终端用户透明无感知。在硬件模式下，GaussDB首先支持多硬件平台能力，如Intel CPU的SGX能力，以及业内首创的华为自主研发鲲鹏ARM TrustZone能力。其次GaussDB实现了最小粒度的隔离级别，使得攻击面最小化，并且通过一系列的密钥安全保障机制，如多层密钥管理体系、可信传输通道、会话级密钥管理机制等，实现了硬件环境中的数据及密钥安全，从而降低因硬件安全问题而导致的用户数据及密钥泄露风险。由于硬件模式依赖于硬件及其生产厂商的安全和信誉，且用户在实际使用过程中需要依赖特性硬件环境，GaussDB还开创性的支持了软件模式的密态查询能力，通过对多种密码学算法的深度性能优化，构建出不同的密态查询引擎，以完成不同的检索和计算功能，实现数据等值查询、范围查询、保序查询、表达式计算等特性。特别的，通过引入确定性加密机制，实现了数据的增删改查、表字段关联、等值检索等基本操作；基于GS-OPE算法的密文索引技术，实现了数据密态保序查询、表达式大小比较等常规操作；通过Range-Identify算法，实现数据密态范围查询。GaussDB 全密态数据库解决方案创新性的解决了多个技术难点，实现了对用户无感知、数据加密无泄漏等核心竞争力。4.2 全自动加密驱动实现用户数据库操作无感知       要实现在客户端进行加解密，无疑需要在客户端进行大量维护管理，包括数据密钥管理，敏感数据加密，解析和修改SQL语句等。如果仅仅提供数据加密工具，由用户来对数据进行显式加密，一方面会增加用户的开发成本，另一方面用户也容易因数据加密不到位而造成数据泄露。GaussDB将这一系列的复杂操作，全部封装在客户端加密驱动中，实现了完全自动化的敏感信息加密替换，同时在数据库中存储了所有加密相关的元信息，使得数据库可以很好的识别和处理对应的加密数据。如图5所示，由于SQL语句中与敏感信息相关的参数也被加密处理，使得发送至数据库服务侧的查询任务(图中ciphertext query)也不会泄露用户查询意图，减少客户端的复杂安全管理及操作难度，实现用户应用开发无感知。另外，GaussDB提供一系列的配置接口，满足用户对加密字段、加密算法、密钥安全存储等不同场景的需要。GaussDB全密态数据库的透明性使得用户在任务迁移时将获得极大的便捷性。图5：全自动客户端加密驱动4.3 利用算子级隔离显著降低安全风险当密文查询进入数据库内核之后，就需要依赖现有的查询处理模块来完成数据运算。对数据库这种高度复杂的系统，在硬件模式下，如何将敏感数据的检索、计算等核心功能解耦隔离，放在安全环境中独立运行，从而最小化敏感数据计算面临的安全风险，一直是GaussDB的一个重大难题。图6：主流硬件隔离方案当前业界主要有三种TEE隔离计算方案：数据库级隔离、模块级隔离、算子级隔离。这三种方案从攻击面和工程实现维度来看，有显著的差异。数据库级隔离，是在TEE中完整的建立一个特殊的数据库引擎，将敏感数据的查询请求直接发送给该数据库进行全部的解析和执行处理。该方案的架构比较清晰，实现简单，安全性和可靠性直接依赖于TEE中数据库的能力。然而，由于TEE中数据库引擎的代码规模较大，因此数据库实例需要消耗更多的TEE侧资源，且一旦由于潜在代码缺陷导致在执行过程出现严重错误，将导致出现TEE环境崩溃等严重后果。模块级隔离，是将SQL执行器放到TEE中，实现对语句的执行过程进行保护。执行器是数据库查询语句的查询任务执行模块，与数据库级隔离相比，这种方式减小了TEE中的代码规模，其安全性主要依赖于执行模块的安全能力。但该方式下仍有大量与敏感数据计算无关的操作将在TEE中运行，而这些操作都可能接触到明文数据，故而容易引入错误或者无意泄露敏感数据，留下安全攻击隐患。算子级隔离。算子是机密数据计算的最小、最核心功能单元，如数据排序算子、表达式计算等。通过将密文算子放在TEE中执行，可以针对性的对敏感数据进行重点保护，排除非敏感数据操作带来的潜在风险，具有最小规模的代码实现。但是其难度和挑战并存：首先，数据库的复杂性决定了将敏感数据的单一算子执行过程进行解耦存在较大的挑战性，传统的pipeline执行流程意味着单个算子执行过程的连续性，针对算子执行过程中的核心计算流程进行解耦就需要进行定向梳理；其次单个查询语句通常涉及多个算子运算，整个查询运算流程需要根据算子运算需求多次切换到TEE侧环境，对性能造成影响。为了追求极致的安全，GaussDB选择了算子级隔离策略。为了解决算子级隔离的两大问题，GaussDB全密态数据库通过精心设计，成功实现了最小粒度的敏感数据检索和计算模块。同时，从多个层面对REE与TEE之间的world switch的性能和数据传输方式进行深度优化，将性能影响降到最低。从而在显著减小安全风险的同时，也有力地保障了数据库系统的高效运行。4.4 高强度密钥体系保障密钥安全       整个全密态数据库解决方案中除数据本身具有敏感性质外，最为敏感的信息就是数据加解密密钥，一旦密钥泄露，将给用户数据带来严重风险。特别是在硬件模式下，密钥需离开用户侧，传输到云侧可信硬件环境中，其安全保护至关重要。GaussDB通过实现三层密钥体系，让各层密钥各司其职，真正做到密钥高强度的安全保护。 图7：GaussDB高强度密钥体系第一层为数据密钥，做到了字段级别，即针对不同的字段将采用不同的密钥，同时对相同字段不同数据采用不同的盐值，以实现不同字段之间的加密隔离，即使某一列数据的加密密钥被泄露，也不会影响到其他数据安全，提升整体数据的安全性。第二层为用户密钥，对不同用户将使用不同的密钥，以实现用户之间的加密隔离，而且用户密钥永远不会离开用户可信环境；使得包括管理员在内的其他用户，即便窃取了数据的访问权限，也无法解密最终数据。 第三层为设备密钥，即对不同的密钥存储设备或工具，使用不同的密钥进行保护，实现设备间的加密隔离，大大增加了攻击用户密钥存储设备或工具破解密钥的难度。       不仅如此，由于在硬件模式下，需要将字段级密钥传输给硬件TEE环境使用。GaussDB在该场景下进行了更高强度的保护措施：首先，通过ECCDH协议安全协商和TEE内置证书签名校验，构建用户侧与TEE环境之间的可信通道，保证密钥安全可信的加密传输，防止中间人攻击；其次，密钥不会以任何形式离开TEE环境，只在会话期间存在，结束立刻释放，最小化数据密钥生命周期，防止因代码漏洞或异常情况引起的密钥泄露。 5、全密态数据库的未来全密态数据库技术理念抛开了传统的多点技术单点解决数据风险的问题，通过系统化思维建立了一套能够覆盖数据全生命周期的安全保护机制。这套机制使得用户在无感知的情况下就解决了数据的安全隐私保护，对于攻击者和管理者来说都无法获取有效信息。全密态数据库是数据库安全隐私保护的高级防御手段，但全密态数据库在当前仍存在一定的局限性，仍需要突破算法安全性和性能损耗等相关问题。全密态数据库在实际应用中建议仅针对敏感数据进行使用，通过借助于数据库本身提供的多方位数据保护机制，为不同等级的数据提供不同层级的安全机制，从而构建全方位的数据安全保护机制。未来GaussDB会将该能力逐步开源到openGauss，与社区共同推进和完善全密态数据库解决方案，一起打造数据库安全生态。

板块：云社区-博客标题：如何把GIS（地理信息）迁移至DWS——抛转引玉链接：https://bbs.huaweicloud.com/blogs/198972如需整改，请及时告知，感谢！

【直播主题和时间】玩转PB级分布式数仓性能调优黑科技2020年10月20日20:00-21:00【活动介绍】本期DevRun开发者沙龙，华为云数仓GaussDB(DWS) 资深优化器专家&调优大师增哥将带大家玩转PB级分布式数仓GaussDB(DWS)性能调优黑科技。凡在本主题帖中留言、参与直播互动或者论坛互动的用户均可参与抽奖，华为手环，蓝牙音箱，移动电源，华为云定制T-shirt等多重好礼等你来拿~【直播地址和报名入口】点击下面链接或扫描图中二维码报名参加直播。直播链接：https://vhall.huawei.com/fe/watch/6305【互动方式】（以下互动方式任选一种或多种）（互动时间截止到10月28日24:00，奖品会在10月30日公布哦）（1）报名参加本次直播；（2）在本主题帖中跟帖盖楼，留言“玩转数仓GaussDB(DWS)性能调优黑科技”；（3）在本主题帖中跟帖留言(包括但不限于直播收获、数仓产品体验感受、平台建议等)；（4）直播互动评论或完成直播调查问卷；（5）在GaussDB(DWS)论坛上发帖互动（问题求助，博文分享，问题解答，产品体验感受，产品优化建议等）；（6）在华为云社区分享博文；（7）参与GuassDB(DWS)产品体验测试。【抽奖方式】1.      幸运互动奖：参与方式： 以上互动方式任选一种或多种参与获奖人数：5名奖励：华为云定制T-shirt 评奖规则：参与华为云社区互动或和直播互动即有机会抽取华为云定制T-shirt。2.优秀评论奖： 直播评论或者跟帖留言用户中选出3名优秀评论奖。 获奖人数：3名奖励：华为nova mini蓝牙音箱（颜色随机）评奖规则：活动结束后从回帖留言用户中评选出3名优秀建议奖（包含参与互动话题）。【参与互动】（可参考以下内容任选一个或多个进行回帖）1.留下您对本次直播的疑问，不限技术，我们都将一一作答2.发表直播观后感3. 回复测试环境验证任意截图 （验证代码及造数脚本请参考附件，基础操作帮助文档及视频请参考华为云数据仓库知识地图）回帖示例：  直播观后感例如：本次直播不但学到了知识还可以…… 3.最佳人气奖：移动电源（先到先得）或华为云定制T-shirt参与方式：参与回帖，并分享邀请小伙伴给自己的回帖进行评论+点赞，在人气高的评论或帖子中抽选若干名奖励：华为定制T-shirt/华为20000mAh移动电源获奖总人数：10名评奖规则：活动结束后按照评论+点赞数进行排序（三部移动电源，先到先得） 4.优秀博文奖：手环1个获奖人数：1名奖励：华为手环评奖规则：1、与直播主题相关 2、有一定技术干货  3、将博文链接作为回帖，活动结束后，会有工作人员从论坛（碎片空间或者精品大作）或者博客中，评选出优秀博文。5. 最佳体验奖获奖人数：3名奖励：1000测试劵+华为三脚架带蓝牙自拍杆/《极简人工智能》书籍评奖规则：活动结束后，回帖申请GaussDB DWS 500元测试券，并进行初步体验，完成所布置的题目，选择三名积极参与并提问的小伙伴获得奖励提醒：测试券使用过程中，如果金额使用完毕，集群未删除会产生欠费，强烈建立费用快结束的时候删除集群。【注意事项】1.获奖结果将在活动结束后5个工作日内进行公示，所有奖品将在活动结束后十五个工作日内发放。2.为防止有恶意发帖行为，同一ID回帖不得超过5条，若超过将取消获奖资格。3.每个ID只能参与一次评选，同一ID不可重复中奖。4.本次回帖内容需满足华为云论坛发帖规范 https://bbs.huaweicloud.com/forum/thread-23077-1-1.html小伙伴们，还在等什么，快快盖楼互动赢大奖吧！！！------------------------------------------------------------------------------------------------------------------------------------------------本期玩转PB级分布式数仓GaussDB(DWS)性能调优黑科技直播互动活动已经结束，感谢各位小伙伴的参与！获得本期玩转PB级分布式数仓GaussDB(DWS)性能调优黑科技直播互动奖励的名单如下，恭喜一下小伙伴~请各位中奖的小伙伴到下面链接反馈收货信息哦^_^  请小伙伴们在2020年11月20日前到下面链接反馈收货信息，逾期礼品作废哦^_^ https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=87226&page=1&extra=#pid452669 【获奖名单】（没有反馈地址的小伙伴快快私信版主反馈获奖地址吧~）奖项中奖人账号/昵称奖品中奖人邮寄地址尺寸幸运互动奖visitor_9675001华为云定制T-shirt已收到幸运互动奖152813袁培仁华为云定制T-shirt已收到幸运互动奖127713徐华为云定制T-shirt已收到幸运互动奖153649郑勇华为云定制T-shirt已收到幸运互动奖137351赵兴旺华为云定制T-shirt待反馈最佳人气奖13811216834华为云定制T-shirt待反馈优秀评论奖153396景晨华为nova mini蓝牙音箱已收到最佳人气奖18510332582华为云定制T-shirt已收到最佳人气奖visitor_8861054华为云定制T-shirt已收到最佳人气奖13516078375华为云定制T-shirt已收到最佳人气奖13752951950华为云定制T-shirt已收到最佳人气奖问道华为云定制T-shirt待反馈最佳人气奖emilyleungbaby华为云定制T-shirt待反馈优秀评论奖帕加尼风之子8866华为nova mini蓝牙音箱已收到最佳人气奖小松鼠华为云定制T-shirt待反馈最佳人气奖神的孩子全跳舞华为云定制T-shirt已收到最佳人气奖152*****608华为云定制T-shirt待反馈优秀评论奖138*****174华为nova mini蓝牙音箱待反馈最佳人气奖狼人移动电源待反馈最佳人气奖爱你一生移动电源待反馈最佳人气奖hw47969246移动电源待反馈

【问题描述】在集群业务数据较大的场景下，从dws页面发起快照备份，可能会花费较长时间，若在备份窗口期内未完成的话可能会影响业务性能，dws较卡的情况，从前台停止备份任务可能存在不能及时响应的问题，在此介绍一种方式从后台强制停止备份任务【解决方案】任意登录一台数据库节点，执行以下命令停止备份任务python $GPHOME/script/GaussRoach.py -t stop -F注：python3环境使用以下命令：python3 $GPHOME/script/GaussRoach.py -t stop -F

1.解密dws密码：[root@25-73-10-21 ~]# kubectl get pods -n dwsNAME                             READY   STATUS    RESTARTS   AGEdwscontroller-7df84784c5-796d7   1/1     Running   0          145ddwscontroller-7df84784c5-ppg76   1/1     Running   0          145d 2.1查到的2个name，随便取一个，执行：kubectl exec -it dwscontroller-7df84784c5-796d7 -n dws bash进入如下目录：[service@dwscontroller-7df84784c5-796d7 logs]$ cd /opt/cloud/3rdComponent/tomcat/webapps/rds/WEB-INF/classes/再执行grep password *拿到最后一行如下数据：taskmgr-config.properties:db.password=d2NjX2NyeXB0ATQxNDU1MzVGNDM0MjQzOzQ2NDM0NDQ2NDEzMzMyMzUzNzMxMzgzOTQ2MzQzNzQ2NDY0NjM1NDUzMzM2NDY0MTQ1NDYzNjM2MzMzMTQyMzEzOTMxMzAzOTMxMzg0NDM1MzQzMDM0MzgzMjM5MzI0NTQyNDQzMjQ1MzEzMTM0MzYzNzQyMzgzNDM0MzczMzM4OzszNTMwMzAzMDMwOzUzNTNFRUFGQkNEMTA4OTRCQUFDOTYwQzVDNDA3NzQ1OzEwRkVDQTJENDBCQTQ5N0U7MzUzMDM2NjQ2NDM1MzEzMzJEMzk2NjYyMzgyRDM0MzkzNzM0MkQzOTY0MzMzNzJENjMzNTMyMzU2NDM2MzkzMjYxMzEzNTY0Ow 3.执行exit退出2进入的容器 4.重新执行进入dws后台命令：kubectl exec -ti dwsmaintaintool-6b57f7fcdb-dvzpp -n dws-maintain /bin/bash进入该目录[root@dwsmaintaintool-6b57f7fcdb-dvzpp opsTool]# 5.执行java -jar AESTool.jar输入：2 d2NjX2NyeXB0ATQxNDU1MzVGNDM0MjQzOzQ2NDM0NDQ2NDEzMzMyMzUzNzMxMzgzOTQ2MzQzNzQ2NDY0NjM1NDUzMzM2NDY0MTQ1NDYzNjM2MzMzMTQyMzEzOTMxMzAzOTMxMzg0NDM1MzQzMDM0MzgzMjM5MzI0NTQyNDQzMjQ1MzEzMTM0MzYzNzQyMzgzNDM0MzczMzM4OzszNTMwMzAzMDMwOzUzNTNFRUFGQkNEMTA4OTRCQUFDOTYwQzVDNDA3NzQ1OzEwRkVDQTJENDBCQTQ5N0U7MzUzMDM2NjQ2NDM1MzEzMzJEMzk2NjYyMzgyRDM0MzkzNzM0MkQzOTY0MzMzNzJENjMzNTMyMzU2NDM2MzkzMjYxMzEzNTY0Ow获得解密后的密码：示例：[root@dwsmaintaintool-6b57f7fcdb-dvzpp opsTool]# java -jar AESTool.jarThis tool need run on jdk1.8+。2016-4-19find  [application.properties] and  use it!other log4j's config has loaded,uses it.log4j:WARN No appenders could be found for logger (org.wcc.crypt.Auditor).log4j:WARN Please initialize the log4j system properly.log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Encrypt,please input 1 and ' ' and password's plaintext [and ' ' and encodedKey's ciphertext]Decrypt,please input 2 and ' ' and password's ciphertext [and ' ' and encodedKey's ciphertext]Encrypt password in file, please input 3 and ' ' and absolute path of file [and ' ' and encodedKey's ciphertext]Decrypt password in file, please input 4 and ' ' and absolute path of file [and ' ' and encodedKey's ciphertext]Encrypt encodedKey, please input 5 and ' ' and encodedKey's plaintextDecrypt encodedKey, please input 6 and ' ' and encodedKey's ciphertextEncrypt multiple-unit passwords, please input 7 and ' ' and absolute path of file with resource tenants infomation in (and ' ' and (0 or 1)){one or more}; 0 not need Encrypt, 1 need EncryptEncrypt RDS-DB password,please input 8 and ' ' and password's plaintextEnd,please input 0 and ' ' and arbitrary character2 d2NjX2NyeXB0ATQxNDU1MzVGNDM0MjQzOzQ2NDM0NDQ2NDEzMzMyMzUzNzMxMzgzOTQ2MzQzNzQ2NDY0NjM1NDUzMzM2NDY0MTQ1NDYzNjM2MzMzMTQyMzEzOTMxMzAzOTMxMzg0NDM1MzQzMDM0MzgzMjM5MzI0NTQyNDQzMjQ1MzEzMTM0MzYzNzQyMzgzNDM0MzczMzM4OzszNTMwMzAzMDMwOzUzNTNFRUFGQkNEMTA4OTRCQUFDOTYwQzVDNDA3NzQ1OzEwRkVDQTJENDBCQTQ5N0U7MzUzMDM2NjQ2NDM1MzEzMzJEMzk2NjYyMzgyRDM0MzkzNzM0MkQzOTY0MzMzNzJENjMzNTMyMzU2NDM2MzkzMjYxMzEzNTY0OwDecrypt result:Xj97cjOaQ2sv#@hIn7 6.执行该命令进入dws后台：sh connectTool.sh -uroot -drms -P3306 -h25.73.10.189 -n "sjzt_dws-dws-cn-cn-2-1" -pXj97cjOaQ2sv#@hIn77.进入成功

发生版本【GaussDB A】【6.5.0】问题描述DWS数据重分布慢，系统盘IO高，数据盘IO很低：                                               问题分析unlink的系统调用底层会调用audit，将系统盘io占满，成为瓶颈，导致重分布业务backend线程阻塞。解决方案以root用户关闭各节点系统审计功能：service auditd stop检查确认系统审计功能已关闭：service auditd status

GaussDB A集群的日志保存路径为“/var/log/Bigdata”,日志目录清单如下：文件目录日志内容/var/log/Bigdata/audit组件审计日志。/var/log/Bigdata/controller日志采集脚本日志。controller进程日志。controller监控日志。/var/log/Bigdata/httpdhttpd日志。/var/log/Bigdata/kerberosKerberos日志。/var/log/Bigdata/ldapclientLDAP客户端日志。/var/log/Bigdata/ldapserverLDAP服务端日志。/var/log/Bigdata/logmanlogman脚本日志管理日志。/var/log/Bigdata/mppMPPDB日志。/var/log/Bigdata/mppmonitorMPPDBMonitor日志。/var/log/Bigdata/nodeagentNodeAgent日志。/var/log/Bigdata/okerberosOMS Kerberos日志。/var/log/Bigdata/oldapserverOMS LDAP日志。/var/log/Bigdata/ommoms：“omm”服务端的复杂事件处理日志、告警服务日志、HA日志、认证与授权管理日志和监控服务运行日志。oma：“omm”代理端的安装运行日志。core：“omm”代理端与“HA”进程失去响应的dump日志。/var/log/Bigdata/sudoSudo日志。/var/log/Bigdata/timestampGaussDB A时间同步管理日志。/var/log/Bigdata/tomcatTomcat日志。/var/log/Bigdata/watchdogWatchdog日志。/var/log/Bigdata/upgrade升级OMS日志。/var/log/Bigdata/patch补丁日志。

问题描述：    执行SQL语句报资源不足的错误， Resource temporarily unavailable 这个错误是Linux报出来的错误。问题分析：通过查看OS的资源配置限制信息，发现Virtual Memory 进行了限制。大小限制为400GB左右。然后查看GaussDB进程的资源占用情况，GaussDB进程占用的虚拟内存也达到了400GB以上，在系统运行的时候会出现资源不足的情况，导致了上面的报错。由于OS将GaussDB的可使用的虚拟内存空间大小进行了400GB的限制，导致GaussDB进程虚拟地址空间不足。解决方案：将ulimit -v unlimited 加入到 omm用户的 .bashrc中。kill om_monitor 检测生效 重启集群。

【问题描述】dws集群升级8.0过程中更新系统表失败，日志中报错用户名或密码无效【问题分析】带sequence的集群升级系统表过程中会涉及切换database，dws切换database需要交互式输入密码，导致升级系统表失败。【解决方案】设置cn dn免密登录后重试gs_guc set -Z coordinator -Z datanode -N all -I all -c 'local   all             all                                     trust'

【摘要】 在GaussDB(DWS)上实现ORACLE的触发器近期项目中遇到客户需要在GaussDB(DWS)上实现ORACLE的触发器。此博文记录一下实现过程。DSC工具转换后，需要手工调整一般SQL语句在ORACLE转换GaussDB(DWS)通过DSC工具转换后，能够直接执行。但触发器转换后，没办法直接执行。参考原来处理的代码，此处整理一个简单的ORACLE的Trigger，然后通过DSC转换后的代码oracle源码CREATE TABLE ORDERS (O_ORDERKEY       INT NOT NULL); CREATE TABLE LINEITEM(L_ORDERKEY    INT NOT NULL, L_PARTKEY     INT NOT NULL); --建触发器 CREATE OR REPLACE TRIGGER  TEST_TRIGGER AFTER INSERT ON ORDERS FOR EACH ROW DECLARE V_O_ORDERKEY INT; begin   V_O_ORDERKEY := :new.O_ORDERKEY;   INSERT INTO LINEITEM VALUES(:new.O_ORDERKEY,1); END test_trigger; /建好触发器后，可以测试一下功能，往ORDERS插入一条数据，看LINEITEM会否有数据插入INSERT INTO ORDERS VALUES (1); SELECT * FROM LINEITEM;DSC转换后CREATE      TABLE           ORDERS (                O_ORDERKEY INT NOT NULL           ) ; CREATE      TABLE           LINEITEM (                L_ORDERKEY INT NOT NULL                ,L_PARTKEY INT NOT NULL           ) ; CREATE OR replace TRIGGER test_trigger AFTER INSERT           ON ORDERS FOR EACH row DECLARE V_O_ORDERKEY INT ; BEGIN V_O_ORDERKEY := :new.O_ORDERKEY ; INSERT      INTO           LINEITEM           VALUES (                :new.O_ORDERKEY                ,1           ) ; END test_trigger ;读者可以尝试拿着这个语句去试跑一下，转换后的语句是需要修改的。DSC转换后修改点1将FOR EACH ROW后面的存储过程内容放到一个函数中，例子如下：create OR replace function test_trigger() returns trigger as $$ DECLARE V_O_ORDERKEY INT ; BEGIN V_O_ORDERKEY := :new.O_ORDERKEY ; INSERT      INTO           LINEITEM           VALUES (                :new.O_ORDERKEY                ,1           ) ; END ;  $$ LANGUAGE plpgsql VOLATILE;然后再建触发器，原文的OR replace去掉，不然会报错CREATE  TRIGGER test_trigger AFTER INSERT           ON ORDERS FOR EACH row  execute procedure  test_trigger();建好触发器后，可以测试一下功能，往ORDERS插入一条数据，看LINEITEM会否有数据插入INSERT INTO ORDERS VALUES (1); SELECT * FROM LINEITEM;GaussDB(DWS)会报如下错误，此时就需要进行修改了DSC转换后修改点2报错的因为ORACLE的触发器中新一行的参数为:new ，而GaussDB(DWS)的新一行参数是不需要冒号:的。所以将函数中:new的:去掉create OR replace function test_trigger() returns trigger as $$ DECLARE V_O_ORDERKEY INT ; BEGIN V_O_ORDERKEY := new.O_ORDERKEY ; INSERT      INTO           LINEITEM           VALUES (                new.O_ORDERKEY                ,1           ) ; END ;  $$ LANGUAGE plpgsql VOLATILE;往ORDERS插入一条数据，看LINEITEM会否有数据插入INSERT INTO ORDERS VALUES (1); SELECT * FROM LINEITEM;发现还是会报错，说没有return值，此处在END前面增加一个RETURN NULL;create OR replace function test_trigger() returns trigger as $$ DECLARE V_O_ORDERKEY INT ; BEGIN V_O_ORDERKEY := new.O_ORDERKEY ; INSERT      INTO           LINEITEM           VALUES (                new.O_ORDERKEY                ,1           ) ; RETURN NULL; END ;  $$ LANGUAGE plpgsql VOLATILE;此时没有报错，触发器也成功实现了功能。实现功能后的优化触发器触发后，执行的一般都是单行条件的SQL。所以要注意建索引，让SQL走indexscan+nestloop的执行计划。但之前遇到的一个情况，就是建了索引以后也存在扫描全表的情况，这样会使触发器执行的很慢。当时遇到的情况是5个表关联，多个表关联可能让执行计划误判，例如A.COL1=B.COL1 .... AND A.COL1=NEW.COL1 这样的关联条件，当时的情况就是B表扫描全表。此处可以等价地增加B表的过滤，例如A.COL1=B.COL1 .... AND A.COL1=NEW.COL1 AND B.COL1 = NEW.COL1 这样的话执行计划就知道走索引扫描了。或者使用hint的方式让B表直接走indexscan。总结ORACLE的触发器是能在GaussDB(DWS)上实现的，但是通过DSC转换工具后，需要进行一定的改写。而触发器的性能不会特别慢，主要基于触发后执行的SQL执行的快慢。之前的经验是触发一个多个大表关联的merge into 语句，插入1000条记录花费的时间是20秒。

【摘要】 GaussDB在执行SQL语句时，会对其性能表现进行分析和记录，通过视图和函数等手段呈现给用户。本文将简要介绍如何利用GaussDB提供的这些“第一手”数据，分析和定位SQL语句中存在的性能问题，识别和消除SQL中的“坏味道”。         SQL语言是关系型数据库（RDB）的标准语言，其作用是将使用者的意图翻译成数据库能够理解的语言来执行。人类之间进行交流时，同样的意思用不同的措辞会产生不同的效果。类似地，人类与数据库交流信息时，同样的操作用不同的SQL语句来表达，也会导致不同的效率。而有时同样的SQL语句，数据库采用不同的方式来执行，效率也会不同。那些会导致执行效率低下的SQL语句及其执行方式，我们称之为SQL中的“坏味道”。         下面这个简单的例子，可以说明什么是SQL中的坏味道。图1-a 用union合并集合         在上面的查询语句中，由于使用了union来合并两个结果集，在合并后需要排序和去重，增加了开销。实际上符合dept_id = 1和dept_id > 2的结果间不会有重叠，所以完全可以用union all来合并，如下图所示。图1-b 用union all合并集合         而更高效的做法是用or条件，在扫描的时候直接过滤出所需的结果，不但节省了运算，也节省了保存中间结果所需的内存开销，如下图所示。图1-c 用or条件来过滤结果         可见完成同样的操作，用不同的SQL语句，效率却大相径庭。前两条SQL语句都不同程度地存在着“坏味道”。         对于这种简单的例子，用户可以很容易发现问题并选出最佳方案。但对于一些复杂的SQL语句，其性能缺陷可能很隐蔽，需要深入分析才有可能挖掘出来。这对数据库的使用者提出了很高的要求。即便是资深的数据库专家，有时也很难找出性能劣化的原因。         GaussDB在执行SQL语句时，会对其性能表现进行分析和记录，通过视图和函数等手段呈现给用户。本文将简要介绍如何利用GaussDB提供的这些“第一手”数据，分析和定位SQL语句中存在的性能问题，识别和消除SQL中的“坏味道”。 ◆ 识别SQL坏味道之自诊断视图         GaussDB在执行SQL时，会对执行计划以及执行过程中的资源消耗进行记录和分析，如果发现异常情况还会记录告警信息，用于对原因进行“自诊断”。用户可以通过下面的视图查询这些信息：•       gs_wlm_session_info•       pgxc_wlm_session_info•       gs_wlm_session_history•       pgxc_wlm_session_history         其中gs_wlm_session_info是基本表，其余3个都是视图。gs_开头的用于查看当前CN节点上收集的信息，pgxc_开头的则包含集群中所有CN收集的信息。各表格和视图的定义基本相同，如下表所示。表1 自诊断表格&函数字段定义名称类型描述datidoid连接后端的数据库OID。dbnametext连接后端的数据库名称。schemanametext模式的名字。nodenametext语句执行的CN名称。usernametext连接到后端的用户名。application_nametext连接到后端的应用名。client_addrinet连接到后端的客户端的IP地址。 如果此字段是null，它表明通过服务器机器上UNIX套接字连接客户端或者这是内部进程，如autovacuum。client_hostnametext客户端的主机名，这个字段是通过client_addr的反向DNS查找得到。这个字段只有在启动log_hostname且使用IP连接时才非空。client_portinteger客户端用于与后端通讯的TCP端口号，如果使用Unix套接字，则为-1。query_bandtext用于标示作业类型，可通过GUC参数query_band进行设置，默认为空字符串。block_timebigint语句执行前的阻塞时间，包含语句解析和优化时间，单位ms。start_timetimestamp with time zone语句执行的开始时间。finish_timetimestamp with time zone语句执行的结束时间。durationbigint语句实际执行的时间，单位ms。estimate_total_timebigint语句预估执行时间，单位ms。statustext语句执行结束状态：正常为finished，异常为aborted。abort_infotext语句执行结束状态为aborted时显示异常信息。resource_pooltext用户使用的资源池。control_grouptext语句所使用的Cgroup。min_peak_memoryinteger语句在所有DN上的最小内存峰值，单位MB。max_peak_memoryinteger语句在所有DN上的最大内存峰值，单位MB。average_peak_memoryinteger语句执行过程中的内存使用平均值，单位MB。memory_skew_percentinteger语句各DN间的内存使用倾斜率。spill_infotext语句在所有DN上的下盘信息：None：所有DN均未下盘。All: 所有DN均下盘。[a:b]: 数量为b个DN中有a个DN下盘。min_spill_sizeinteger若发生下盘，所有DN上下盘的最小数据量，单位MB，默认为0。max_spill_sizeinteger若发生下盘，所有DN上下盘的最大数据量，单位MB，默认为0。average_spill_sizeinteger若发生下盘，所有DN上下盘的平均数据量，单位MB，默认为0。spill_skew_percentinteger若发生下盘，DN间下盘倾斜率。min_dn_timebigint语句在所有DN上的最小执行时间，单位ms。max_dn_timebigint语句在所有DN上的最大执行时间，单位ms。average_dn_timebigint语句在所有DN上的平均执行时间，单位ms。dntime_skew_percentinteger语句在各DN间的执行时间倾斜率。min_cpu_timebigint语句在所有DN上的最小CPU时间，单位ms。max_cpu_timebigint语句在所有DN上的最大CPU时间，单位ms。total_cpu_timebigint语句在所有DN上的CPU总时间，单位ms。cpu_skew_percentinteger语句在DN间的CPU时间倾斜率。min_peak_iopsinteger语句在所有DN上的每秒最小IO峰值（列存单位是次/s，行存单位是万次/s）。max_peak_iopsinteger语句在所有DN上的每秒最大IO峰值（列存单位是次/s，行存单位是万次/s）。average_peak_iopsinteger语句在所有DN上的每秒平均IO峰值（列存单位是次/s，行存单位是万次/s）。iops_skew_percentinteger语句在DN间的IO倾斜率。warningtext显示告警信息。queryidbigint语句执行使用的内部query   id。querytext执行的语句。query_plantext语句的执行计划。node_grouptext语句所属用户对应的逻辑集群。         其中的query字段就是执行的SQL语句。通过分析每个query对应的各字段，例如执行时间，内存，IO，下盘量和倾斜率等等，可以发现疑似有问题的SQL语句，然后结合query_plan（执行计划）字段，进一步地加以分析。特别地，对于一些在执行过程中发现的异常情况，warning字段还会以human-readable的形式给出告警信息。目前能够提供的自诊断信息如下：◇多列/单列统计信息未收集         优化器依赖于表的统计信息来生成合理的执行计划。如果没有及时对表中各列收集统计信息，可能会影响优化器的判断，从而生成较差的执行计划。如果生成计划时发现某个表的单列或多列统计信息未收集，warning字段会给出如下告警信息：Statistic Not Collect:schemaname.tablename(column name list)         此外，如果表格的统计信息已收集过（执行过analyze），但是距离上次analyze时间较远，表格内容发生了很大变化，可能使优化器依赖的统计信息不准，无法生成最优的查询计划。针对这种情况，可以用pg_total_autovac_tuples系统函数查询表格中自从上次分析以来发生变化的元组的数量。如果数量较大，最好执行一下analyze以使优化器获得最新的统计信息。 ◇SQL未下推         执行计划中的算子，如果能下推到DN节点执行，则只能在CN上执行。因为CN的数量远小于DN，大量操作堆积在CN上执行，会影响整体性能。如果遇到不能下推的函数或语法，warning字段会给出如下告警信息：SQL is not plan-shipping, reason : %s ◇Hash连接大表做内表         如果发现在进行Hash连接时使用了大表作为内表，会给出如下告警信息：PlanNode[%d] Large Table is INNER in HashJoin \"%s\"目前“大表”的标准是平均每个DN上的行数大于100，000，并且内表行数是外表行数的10倍以上。 ◇大表等值连接使用NestLoop         如果发现对大表做等值连接时使用了NestLoop方式，会给出如下告警信息：PlanNode[%d] Large Table with Equal-Condition use Nestloop\"%s\"目前大表等值连接的判断标准是内表和外表中行数最大者大于DN的数量乘以100，000。 ◇数据倾斜         数据在DN之间分布不均匀，可导致数据较多的节点成为性能瓶颈。如果发现数据倾斜严重，会给出如下告警信息：PlanNode[%d] DataSkew:\"%s\", min_dn_tuples:%.0f, max_dn_tuples:%.0f目前数据倾斜的判断标准是DN中行数最多者是最少者的10倍以上，且最多者大于100,000。 ◇代价估算不准确         GaussDB在执行SQL语句过程中会统计实际付出的代价，并与之前估计的代价比较。如果优化器对代价的估算与实际的偏差很大，则很可能生成一个非最优化的计划。如果发现代价估计不准确，会给出如下告警信息："PlanNode[%d] Inaccurate Estimation-Rows: \"%s\" A-Rows:%.0f, E-Rows:%.0f目前的代价由计划节点返回行数来衡量，如果平均每个DN上实际/估计返回行数大于100,000，并且二者相差10倍以上，则认定为代价估算不准。 ◇Broadcast量过大         Broadcast主要适合小表。对于大表来说，通常采用Hash+重分布（Redistribute）的方式效率更高。如果发现计划中有大表被广播的环节，会给出如下告警信息：PlanNode[%d] Large Table in Broadcast \"%s\"目前对大表广播的认定标准为平均广播到每个DN上的数据行数大于100,000。 ◇索引设置不合理  如果对索引的使用不合理，比如应该采用索引扫描的地方却采用了顺序扫描，或者应该采用顺序扫描的地方却采用了索引扫描，可能会导致性能低下。索引扫描的价值在于减少数据读取量，因此认为索引扫描过滤掉的行数越多越好。如果采用索引扫描，但输出行数/扫描总行数>1/1000，并且输出行数>10000（对于行存表）或>100（对于列存表），则会给出如下告警信息：PlanNode[%d] Indexscan is not properly used:\"%s\", output:%.0f, filtered:%.0f, rate:%.5f顺序扫描适用于过滤的行数占总行数比例不大的情形。如果采用顺序扫描，但输出行数/扫描总行数<=1/1000，并且输出行数<=10000（对于行存表）或<=100（对于列存表），则会给出如下告警信息：PlanNode[%d] Indexscan is ought to be used:\"%s\", output:%.0f, filtered:%.0f, rate:%.5f ◇下盘量过大或过早下盘         SQL语句执行过程中，因为内存不足等原因，可能需要将中间结果的全部或一部分转储的磁盘上。下盘可能导致性能低下，应该尽量避免。如果监测到下盘量过大或过早下盘等情况，会给出如下告警信息：•       Spill file size large than 256MB•       Broadcast size large than 100MB•       Early spill•       Spill times is greater than 3•       Spill on memory adaptive•       Hash table conflict         下盘可能是因为缓冲区设置得过小，也可能是因为表的连接顺序或连接方式不合理等原因，要结合具体的SQL进行分析。可以通过改写SQL语句，或者HINT指定连接方式等手段来解决。          使用自诊断视图功能，需要将以下变量设成合适的值：▲ use_workload_manager（设成on，默认为on）▲ enable_resource_check（设成on，默认为on）▲ resource_track_level（如果设成query，则收集query级别的信息，如果设成operator，则收集所有信息，如果设成none，则以用户默认的log级别为准）▲ resource_track_cost（设成合适的正整数。为了不影响性能，只有执行代价大于resource_track_cost语句才会被收集。该值越大，收集的语句越少，对性能影响越小；反之越小，收集的语句越多，对性能的影响越大。）         执行完一条代价大于resource_track_cost后，诊断信息会存放在内存hash表中，可通过pgxc_wlm_session_history或gs_wlm_session_history视图查看。         视图中记录的有效期是3分钟，过期的记录会被系统清理。如果设置enable_resource_record=on，视图中的记录每隔3分钟会被转储到gs_wlm_session_info表中，因此3分钟之前的历史记录可以通过gs_wlm_session_info表或pgxc_wlm_session_info视图查看。  ◆ 发现正在运行的SQL的坏味道         上一节提到的自诊断视图可以显示已完成SQL的信息。如果要查看正在运行的SQL的情况，可以使用下面的视图：•       gs_wlm_session_statistics•       pgxc_wlm_session_statistics         类似地，gs_开头的用于查看当前CN节点上收集的信息，pgxc_开头的则包含集群中所有CN收集的信息。两个视图的定义与上一节的自诊断视图基本相同，使用方法也基本一致。 通过观察其中的字段，可以发现正在运行的SQL中存在的性能问题。         例如，通过“select queryid, duration from gs_wlm_session_statistics order by duration desc limit 10;”可以查询当前运行的SQL中，已经执行时间最长的10个SQL。如果时间过长，可能有必要分析一下原因。图2-a 通过gs_wlm_session_statistics视图发现可能hang住SQL         查到queryid后，可以通过query_plan字段查看该SQL的执行计划，分析其中可能存在的性能瓶颈和异常点。图2-b 通过gs_wlm_session_statistics视图查看当前SQL的执行计划         再下一步，可以结合等待视图等其他手段定位性能劣化的原因。图2-c 通过gs_wlm_session_statistics视图结合等待视图定位性能问题         另外，活动视图pg_stat_activity也能提供一些当前执行SQL的信息。 ◆ Top SQL——利用统计信息发现SQL坏味道         除了针对逐条SQL进行分析，还可以利用统计信息发现SQL中的坏味道。另一篇文章“Unique SQL特性原理与应用”中提到的Unique SQL特性，能够针对执行计划相同的一类SQL进行了性能统计。与自诊断视图不同的是，如果同一个SQL被多次执行，或者多个SQL语句的结构相同，只有条件中的常量值不同。这些SQL在Unique SQL视图中会合并为一条记录。因此使用Unique SQL视图能更容易看出那些类型的SQL语句存在性能问题。         利用这一特性，可以找出某一指标或者某一资源占用量最高/最差的那些SQL类型。这样的SQL被称为“Top SQL”。         例如，查找占用CPU时间最长的SQL语句，可以用如下SQL：select unique_sql_id,query,cpu_time from pgxc_instr_unique_sql order by cpu_time desc limit 10。         Unique SQL的使用方式详见https://bbs.huaweicloud.com/blogs/197299。 ◆ 结论         发现SQL中的坏味道是性能调优的前提。GaussDB对数据库的运行状况进行了SQL级别的监控和记录。这些打点记录的数据可以帮助用户发现可能存在的异常情况，“嗅”出潜在的坏味道。从这些数据和提示信息出发，结合其他视图和工具，可以定位出坏味道的来源，进而有针对性地进行优化。【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区），文章链接，文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：huaweicloud.bbs@huawei.com进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。