【摘要】 在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进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。

1、停止集群cm_ctl stopcm_ctl stop -mi 2、启动集群cm_ctl start     起停实例：        cm_ctl stop -n 1 -D /srv/BigData/mppdb/data1/coordinator        cm_ctl start -n 1 -D /srv/BigData/mppdb/data1/coordinator3、主备切换cm_ctl switchover -n 1 -D /srv/BigData/mppdb/data1/slave2 4、均衡整个集群cm_ctl switchover -acm_ctl switchover -n nodeid -D /srv/BigData/mppdb/data2 -q注意是否有catchup:select * from pgxc_get_senders_catchup_time();5、实例修复1）全量build：在任意节点执行：cm_ctl build -n 1 -D /srv/BigData/mppdb/data2/slave1 -b full -t 10800在需要build实例所在节点执行：gs_ctl build -D /srv/BigData/mppdb/data2/slave1 -Z datanode -b full -r 108002）节点修复：gs_replace -t config -h 10-145-255-203                             gs_replace -t start-h 10-145-255-2036、强制升主（慎用）：前提：从备实例pg_xlog与base/dummy_standby/是否为空kill pid; sleep 5;gs_ctl notify -M primary -D7、gaussdb重启标志log：Initialize Communication Layer8、查看HA状态信息：receiver_replay_location等gs_ctl query -D  /data1/mppdb/master19、解析xlogpg_xlogdump $xlog文件名10、解析数据库文件：pagehack查看 行存数据页面查看 行存索引页面查看 列存数据页面查看 cu11、sql常用视图：活跃视图：select * from pg_stat_activity where state = 'active';等待视图：select * from pgxc_thread_wait_status; 12、重分布相关视图：1）查看重分布整体进度，重分布结束后会被删除：select * from redis_progress order by name;2）记录了数据库中每张表重分布所耗时间：redis_progress_detail;3）查看需要重分布的表，重分布结束后会删除：pgxc_redistb4）重分布目前所处状态：redis_status13、GaussDB实例退出场景：1）进程被os oom kill：如果能对应上就是os kill了gaussdb的进程（由于内存用的太多，要看看你们配置的max_process_memory是不是太大了)2）进程主动退出：需要查看具体的pg_log，看看退出原因3）进程core：需要配置os core配置，生产core，进一步分析，os message可能会有segment fault打印等信息参考。4）被CMA kill：可以看对应时间点是否有CMA kill实例日志14、符号表路径常用与有GaussDB实例产生core需要解析core文件时加载对应符号表，注意该路径为一个参考实例其中标红部分根据集群版本不同进行灵活变通即可。/opt/huawei/Bigdata/FusionInsight_MPPDB_6.5.1.9/install/FusionInsight-MPPDB-6.5.1/package/MPPDB_ALL_PACKAGE15、磁盘读写策略一般常用于排查磁盘读写慢的问题，一般推荐设置为write-back/write-back-BBU（有的可能会设置成write-through，这种会导致读写较慢不建议设置）查看磁盘读写策略：/opt/MegaRAID/MegaCli/MegaCli64 -cfgdsply -aALL|grep "Current Cache Policy"修改磁盘读写策略为wb：/opt/MegaRAID/storcli/storcli64 /c0/v1 set wrcache=wb附录：判断实例是否在redo：https://bbs.huaweicloud.com/forum/thread-75275-1-1.htmlGaussDB catchup时间长问题排查：https://bbs.huaweicloud.com/forum/thread-75411-1-1.htmlGaussDB某一节点文件描述符耗尽预防：https://bbs.huaweicloud.com/forum/thread-75465-1-1.htmlGaussDB任务hang问题定位：https://bbs.huaweicloud.com/blogs/174795?ticket=ST-657753-ANlEJlpeioQdCGbquWlu9J0W-sso&locale=zh-cn#commentGaussDB磁盘满问题排查 https://bbs.huaweicloud.com/blogs/174806GaussDB 集群状态异常应急案例（全）https://bbs.huaweicloud.com/forum/thread-83202-1-1.html

来这里，您可以获得l  GaussDB互联网应用场景解决方案l  加入云推官，推荐新客下单即获奖励l  最高返利8万元，现金返利不拆分华为自研GaussDB系列重磅发布：最新一代DFV 存储云原生企业级分布式数据库业界领先的存储+网络+鲲鹏算力全栈软硬自研可控政企智能化升级优选1、GaussDB适用哪些场景：GaussDB(for MySQL): 金融行业/政府/运营商/大企业GaussDB NoSQL（多模NoSQL非关系型数据库Mongo、Cassandra、Redis、Influx）：游戏、电商、娱乐社交、物联网2、华为云数据库产品已经服务了500+政企客户，助力千行百业。华为云GaussDB成为企业智能升级的数据库首选。更多客户故事点击这里查看3、全场低至5折，限时特惠，机惠不容错过~ 活动直通车活动时间：2020年9月12日至2020年10月31日。4、GaussDB系列产品优势：GaussD(for MySQL)与GaussDB NoSQL在数据安全、弹性扩容、性能、备份恢复方面都有极大的提升有更多问题请咨询华为云数据库小助手，活动直达：https://activity.huaweicloud.com/gaussdb.html

【软件名称】GaussDB 200【软件版本】6.5.1 单节点安装【问题现象】按照6.5.1安装手册进行的，但是初始化集群报错过不去【问题影响】无法启动集群我在论坛看到别人也出现过这个错误，是因为配置DN结点的数量导致的。但是我们DN配置应该是正确的，但是仍然出现了这个错误，找了好久都没有解决错误日志为[2020-09-08 20:23:43]Begin to register default accounts.[2020-09-08 20:23:43]End to register default accounts.[2020-09-08 20:23:43]Initialize service for Service[name: MPPDB, displayName: MPPDB, cluster: test916].[2020-09-08 20:23:43]Initialize role for ROLE[name: MPPDBServer, serviceDisplayName: MPPDB, cluster: test916].[2020-09-08 20:23:43]Initialize roleInstance for MPPDBServer#10.28.187.169@gaussa.[2020-09-08 20:23:58]RoleInstance cleanup success for MPPDBServer#10.28.187.169@gaussa.[2020-09-08 20:24:52]RoleInstance initialization failure [{ScriptExecutionResult=ScriptExecutionResult [exitCode=1, output=ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDfnqxH7hq45PWvFIw7tV1QUeZfg/1X/MI3YaJgqJEmezLlQUhtdTucZjhoPmTRMDYhLfDw1NsE/+FEjoxTUg6F2WZTUv7ZLnUNzFCZPWU3i63Ts3Q8wvkH//6Jr51th1UAIX5J8HADzUT9NrosSVGYQZsUE1oER1Cw1xVbrLSLaggx+MdpI7M7kP9DvNbE0SNwRwHM3lN2MecfCMfrFVUbOM/QCohV47E1IU31wHXGa5CKBcKBMy6YWgQjMPWFqw/kqpzNxoXZt9/TV43nEMQKesh3vKvTsTJJ49iOLYp1thZJE/qrD5n686e+wGsXxH+pyNxkiYJTfJgbcahwLwNb omm@gaussa, errMsg=Warning: Permanently added '10.28.187.169' (ECDSA) to the list of known hosts.scp: /opt/GaussDB200/app/mppdb/gs_install_success: No such file or directoryWarning: Permanently added '10.28.187.169' (ECDSA) to the list of known hosts.Warning: Permanently added '10.28.187.169' (ECDSA) to the list of known hosts.Warning: Permanently added '10.28.187.169' (ECDSA) to the list of known hosts.Warning: Permanently added '10.28.187.169' (ECDSA) to the list of known hosts.Warning: Permanently added '10.28.187.169' (ECDSA) to the list of known hosts.]}] for MPPDBServer#10.28.187.169@gaussa.[2020-09-08 20:24:52]Role initialization failure for Service[name: MPPDB, displayName: MPPDB, cluster: test916].

explain可以打印SQL的执行计划，根据执行计划的一些特征，我们可以发现一些明显的烂SQL的特征，具有这些特征的SQL一般都是执行性能很差的，需要调优的。不下推的语句：explain verboseselect distinct on (c1) test1.a c1from test1, test2where test1.a = test2.b;不下推语句会有类似上述的关键字，性能会比较差。在cn节点的pg_log中，可以找到对应语句的不下推的原因。2. 执行计划中有SubPlan：select     1,    (select count(*) from customer_address_001 a4 where a4.ca_address_sk = a.ca_address_sk) as GZCS from customer_address_001 a;如果执行计划中有SubPlan关键字，一般这种SQL的性能都比较差。要想办法改写。在新版本中，优化器可以支持更多场景的这种自动转化，请大家根据实际版本对应的执行计划，根据需要来改写上述逻辑。3. NestLoop + indexScan的误用一般来说， NestLoop + indexScan这种计划适用用两表关联后返回结果集比较小的情况，并且索引是btree索引的场景，但是某些场景下，可能出现优化器估算不准，在并不适合这种场景下，选择了这种计划，就会到执行性能很差。一般处理这种问题，就是设置参数set enable_index_nestloop = off来调优。4. 其他场景，后续补充

直播回看地址：https://bbs.huaweicloud.com/webinar/100019“全部直播”部分选择技术领域“Gauss AP”可以查看到全部直播内容本次直播是五节课的系列课程，课程计划如下：第四天直播会讲解GaussDB(DWS)的日常巡检，常见问题定位方法（包括网络，集群，存储等）。扫描以下海报二维码即可进入直播间，也可通过链接进入：https://huawei.vhallyun.com/fe/watch/5147【学习福利】想要利用坐地铁，排队等零碎时间来学习专业数据库知识吗？马上扫描华为云AI微信公众号“华为云AI”，带给你不一样的资讯，除了华为云数仓及人工智能相关技术类精品文章外，也可以手机端登陆论坛提问并查看技术分享。GaussDB(DWS)产品主页：https://www.huaweicloud.com/product/dws.html     GaussDB(DWS)产品主页二维码HCIP-GaussDB-OLAP认证介绍与预约考试：https://e.huawei.com/cn/talent/#/cert/product-details?certifiedProductId=195&authenticationLevel=CTYPE_CARE_HCIP&technicalField=PSC&version=1.0

直播回看地址：https://bbs.huaweicloud.com/webinar/100019“全部直播”部分选择技术领域“Gauss AP”可以查看到全部直播内容本次直播是五节课的系列课程，课程计划如下：第四天直播会讲解GaussDB(DWS)补丁、升级与扩容流程，数据库备份恢复的技术。扫描以下海报二维码即可进入直播间，也可通过链接进入：https://huawei.vhallyun.com/fe/watch/5146【学习福利】想要利用坐地铁，排队等零碎时间来学习专业数据库知识吗？马上扫描华为云AI微信公众号“华为云AI”，带给你不一样的资讯，除了华为云数仓及人工智能相关技术类精品文章外，也可以手机端登陆论坛提问并查看技术分享。GaussDB(DWS)产品主页：https://www.huaweicloud.com/product/dws.html     GaussDB(DWS)产品主页二维码HCIP-GaussDB-OLAP认证介绍与预约考试：https://e.huawei.com/cn/talent/#/cert/product-details?certifiedProductId=195&authenticationLevel=CTYPE_CARE_HCIP&technicalField=PSC&version=1.0

问题描述：某局点的的其中一个节点，周期性（20s）出现cpu使用率100%情况，而占用cpu的任务是同时被拉起的大量的lspci操作观察任务树发现，该任务的父进程关系非常奇怪父进程和子进程基本是八竿子打不着的关系本地排查了1、ssh -vvv以及其他尝试构造该场景，未发现2、远端通过ssh连接到本服务器，然后执行lspci3、查看om fim监控脚本，无相关lspci调用，排除。在排除了几个可疑点之后，再次观察状态树，怀疑是ssh登录后脚本导致，最终发现，该命令实际是通过登录后的/etc/profile中，拉起了lspci根因分析：由于redhat在ssh登陆时，会自动加载/etc/bashrc脚本，该脚本会将/etc/profile.d/ 目录下所有的sh脚本加载一遍，系统的qt（一个开源的桌面开发工具）自带的环境变量检查里面会调用lspci解决方案：目前qt工具在我们系统中用不上，直接将所有节点的/etc/profile.d/qt*.sh的脚本注释掉问题解析：当前Gaussdb内部的一些检测和运维的原理都是依赖于'ssh hostname cmd'这种方式来进行远程控制，因此对于ssh登陆效率和性能本身有一定的依赖，建议系统安装时采用最小方式安装，对于无关的应用，建议不要安装在服务器上

【机制说明】GaussDB实例catchup分为以下两种：1）数据页catchup：一般出现在备机故障一段时间修复后重新连主时，从主机追赶落后数据。2）日志catchup：一般常见于带索引导入时主机产生过多xlog文件，备机来不及接收出现。对于以上catchup过程慢一般没有太多应对措施，在此我们主要讨论catchup时间过长，此时查看日志排除是否产生死锁造成catchup永远执行不完。【问题描述】查看集群状态长时间（超过24小时甚至更长时间）有实例处于catchup状态【问题分析】1、查看主DN实例是否有以下日志：2、出现该问题是由于catchup与dml语句抢锁导致，此时kill正在执行的dml语句即可，或停止一段之间业务让catchup做完，不然可能会与新进来的业务一直抢锁导致catchup无法结束。

直播回看地址：https://bbs.huaweicloud.com/webinar/100019“全部直播”部分选择技术领域“Gauss AP”可以查看到全部直播内容本次直播是五节课的系列课程，课程计划如下：第三天直播会深入讲解事务与锁机制管理，资源负载管理，性能调优，安全与权限设计，非常具有实操性。扫描以下海报二维码即可进入直播间，也可通过链接进入：https://huawei.vhallyun.com/fe/watch/5145【学习福利】想要利用坐地铁，排队等零碎时间来学习专业数据库知识吗？马上扫描华为云AI微信公众号“华为云AI”，带给你不一样的资讯，除了华为云数仓及人工智能相关技术类精品文章外，也可以手机端登陆论坛提问并查看技术分享。GaussDB(DWS)产品主页：https://www.huaweicloud.com/product/dws.html     GaussDB(DWS)产品主页二维码HCIP-GaussDB-OLAP认证介绍与预约考试：https://e.huawei.com/cn/talent/#/cert/product-details?certifiedProductId=195&authenticationLevel=CTYPE_CARE_HCIP&technicalField=PSC&version=1.0

前言： GaussDB经常会碰到实例长期处于need repair状态，kill该实例或者手动拉起该实例一直处于need repair状态，此时可能该实例可能在做redo，完成后即可变成normal状态。按照以下步骤判断该实例是否在做redo。方式一：快速判断，查看实例堆栈：ps -ef|grep xxxx |grep -v grep|awk '{print $2}'|xargs gstack ，存在redo相关线程即能确定该实例正在redo。注：将xxx替换为对应实例路径方式二：连接该DN查看redoLSN位置是否有变化：select pg_last_xlog_replay_location();连续查看该值若有变动那么该实例正在做redo查看还有多少xlog需要redo：进入该实例目录下pg_xlog路径查看最新xlog lsn位置，ll -thr|tail -n 10根据以上查询结果目前redo到8F5，最新xlog为8F9，差一个数xlog大小为4G，此时还有16G（4*4）的xlog未同步方式三：该方式适合主备实例正常情况下使用，查看正常实例同步及备机redo进度，gs_ctl query -D 主实例目录主机最新xlog为8EE，目前备机redo位置为8E8，目前还有24Gxlog未redo方式四：lsof -p $pid|grep 00000*查看目前该实例 redo到那个xlog文件附：解析xlog文件查看需要redo的内容：1）解析详细内容：pg_xlogdump xlog_file解析该文件发现有较多truncate操作需要进行redo。2）统计xlog文件信息：pg_xlogdump -z xlog_file

背景> 数据库数据迁移过程，特别是迁移过程中，双方数据双加载过程中，如何校验数据加工一致时，引出了数据一致性比对；> 本节只是提供校验的方法，供大家探讨；具体解决方案可联系楼主。数值型> 除了本身精度不确定类型，双方用法一致，可以直接sum聚合；时间型>时间可以分为time、date（TD兼容模式下日期格式）、timestamp>实现思路，均将时间信息转换成数字，再进行sum聚合；time统一转成0点开始的时间秒；>TD实现sel extract(hour from time'12:12:12')*3600+extract(minute from time'12:12:12')*60+extract(second from time'12:12:12');>GS实现select extract(epoch from '12:12:12'::time);date统一转成1970年元旦开始的天数；>TD实现sel (date'2020-08-19'-date'1970-01-01')*86400;>GS实现select extract(epoch from '20200819'::date);timestamp统一转成1970年元旦开始的秒数；>TD实现sel ( (timestamp'2020-08-19 12:12:12'(date))-date'1970-01-01')*86400     +extract(hour from timestamp'2020-08-19 12:12:12')*3600     +extract(minute from timestamp'2020-08-19 12:12:12')*60     +extract(second from timestamp'2020-08-19 12:12:12');>GS实现select extract(epoch from '2020-08-19 12:12:12'::timestamp);字符型> 和字符集强相关，目前只支持英文、数值、半角符号的checksum聚合；> 主要指char/varchar类型；当然其它类型可显式或隐式转为格式一致的字符型；> 比对实现机制，计算单个字符串的md5值，再经过二次异或加工，转成数字，就可以进行sum聚合；> TD实现replace function xor_md5(inpt varchar(32000)) returns bigint language sql deterministic contains sql sql SECURITY DEFINER collation INVOKER INLINE TYPE 1 return  bitxor( bitxor ( bitxor ( cast(from_bytes(to_bytes(translate(substr(hash_md5(inpt),1,8) using latin_to_unicode),'base16'),'base10') as bigint) ,cast(from_bytes(to_bytes(translate(substr(hash_md5(inpt),9,8) using latin_to_unicode),'base16'),'base10') as bigint)) ,cast(from_bytes(to_bytes(translate(substr(hash_md5(inpt),17,8) using latin_to_unicode),'base16'),'base10') as bigint)) ,cast(from_bytes(to_bytes(translate(substr(hash_md5(inpt),25,8) using latin_to_unicode),'base16'),'base10') as bigint)); select sum((xor_md5(colA))::dec(38,0)) as chksum from table_a;>GS实现create function xor_md5(text) returns bigint immutable as $$ select ('x'||lpad(substr(md5($1),1,8),16,'0'))::bit(64)::bigint       # ('x'||lpad(substr(md5($1),9,8),16,'0'))::bit(64)::bigint       # ('x'||lpad(substr(md5($1),17,8),16,'0'))::bit(64)::bigint      # ('x'||lpad(substr(md5($1),25,8),16,'0'))::bit(64)::bigint; $$ language sql; select sum(xor_md5(colA)(dec(38,0))) as chksum from table_a;若TD字符集是LATIN存GBK（国内客户常见），可以采用下述自定义函数替换：create function xor_md5(text) returns bigint immutable as $$ select ('x'||lpad(substr(md5(convert_to($1,'GBK')),1,8),16,'0'))::bit(64)::bigint       # ('x'||lpad(substr(md5(convert_to($1,'GBK')),9,8),16,'0'))::bit(64)::bigint       # ('x'||lpad(substr(md5(convert_to($1,'GBK')),17,8),16,'0'))::bit(64)::bigint      # ('x'||lpad(substr(md5(convert_to($1,'GBK')),25,8),16,'0'))::bit(64)::bigint; $$ language sql; select sum(xor_md5(colA)(dec(38,0))) as chksum from table_a;

CREATE FUNCTION random_str(length integer) RETURNS character varying    LANGUAGE plpgsql IMMUTABLE NOT SHIPPABLE    AS $_$DECLAREresult varchar;BEGINselect array_to_string(array(select substring('0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' FROM (ceil(random()*62))::int FOR 1) FROM generate_series(1, $1)),'a','null') INTO result;return result;END$_$;

--创建测试表并插入数据create table t1(a int,b varchar,c varchar);insert into t1 values(1,'张学友','aaaaaaaaaa'),(2,'刘德华','bbbbbbbbbbbbb'),(3,'郭富城','ccccccccccccc'),(4,'黎明','ddddddddddddd'),(5,'周润发','eeeeeeeeeeeeeee'),(6,'吴彦祖','fffffffffffff');create table t2(a int,b varchar,c varchar);insert into t2 values(1,'张学友','aaaaaaaaaa'),(2,'刘德华','bbbbbbbbbbbbb'),(3,'郭富城','ccccccccccccc'),(3,'郭富城','ccccccccccccc'),(2,'刘德华','bbbbbbbbbbbbb');执行查询1（join）：select * from t1,t2 where t1.a=t2.a;执行查询2(in)：select * from t1 where t1.a in (select t2.a from t2);