如题，怎么查看？我知道pg_get_indexdef可以看某个索引的定义。但是想通过字典表查如题的信息。

DIS支持将源数据类型为JSON格式的数据转储至DWS。转储前，需要配置源数据Schema。源数据Schema，即用户的JSON数据样例，用于描述JSON数据格式。DIS可以根据此JSON数据样例生成Avro schema, 将通道内上传的JSON数据转换为Parquet或CarbonData格式。参考创建源数据Schema，创建源数据Schema。如下以添加转储任务时创建源数据Schema为例进行说明。选择源数据类型是Json的通道。在通道详情页面的“转储任务”页签，单击“添加转储任务”。转储服务类型选择DWS，通过导入文件的方式配置源数据Schema。输入源数据样例，单击“转换源数据样例”并提交，生成源数据Schema。配置Schema属性过滤功能。说明： schema过滤功能，只针对源数据schema根节点或一级子节点非array类型，才有效。即管理源数据Schema创建的源数据schema，满足根节点或一级子节点非array类型，界面才呈现此配置。打开Schema过滤开关。在源数据属性名列表中，勾选对应的属性名，完成DWS表中指定列的映射。说明： 源数据属性名列表中的属性由源数据Schema的name字段生成，匹配DWS的列名称。如图2所示，源数据属性名只选择id，即少于对应表的总字段。DWS侧创建集群，并执行如下命令创建表。CREATE TABLE dis_test3(id TEXT,dev TEXT,online BIGINT,module TEXT default 'a',logTime TEXT,appId TEXT,event TEXT);DIS侧转储数据至DWS成功后，登录集群数据库查询dis_test3表格数据，可看到仅id列和module列插入数据，其中module列是默认数据。

【直播时间】DevRun开发者沙龙直播时间：2020年8月14日 20:00~21:00【活动介绍】本期DevRun开发者沙龙，将由华为云数据库研发专家  GoldenJohn，为你揭秘GaussDB(for Mongo) 秒级水平扩展独家秘籍。凡报名参加线上直播或在本主题帖中留言的用户均可参与抽奖，奖品若干！ 【报名入口】点击下面链接或扫描微信二维码报名参加直播。报名链接：https://bbs.huaweicloud.com/signup/fa23d72deee34848ba261282a1648839报名二维码：【直播地址】1.微吼直播间：http://live.vhall.com/1823184392.华为云B站：http://live.bilibili.com/219454223.华为云斗鱼：https://www.douyu.com/huaweiyun4.华为云虎牙：https://www.huya.com/huaweiyun 【互动送好礼】满足下面的一个条件即可参与抽奖：1、报名参加直播。2、在本主题帖中跟帖，留言“GaussDB(for Mongo) 秒级水平扩展真牛”。3、在本主题帖中跟帖，留言“提问：xxx”、“建议：xxx”或“反馈：xxx”等。 【获奖规则】1、幸运奖：海纳斯小风扇，从报名入口完成报名的直播用户和本主题留言用户中，随机抽取若干名。2、互动奖：毕亚兹运动臂包，在本主题的留言中，选取最优秀的回帖若干名。3、同一个用户只有一个礼品。4、为保证公平公正，抽奖结果将在活动结束后7个工作日内本主题帖中发布，请报名和留言的伙伴关注社区内容。【礼品展示】【获奖用户】幸运奖：海纳斯小风扇Youhoo帕加尼风之子8866Jazzup小果果user_beifengwolfkdyhw59398218CHAOYING互动奖：毕亚兹运动臂包CharlesE孙小北hw46018172问道linghz666恭喜以上用户获得本期DevRun开发者沙龙直播社群互动奖，我们已私信您填写收件信息的链接，请您注意查看，我们会尽快发出奖品。如您未在8月27日之前提交获奖信息，视为您自动放弃。望周知。

目录：                  GaussDB Roach逻辑备份恢复原理gs_dump逻辑备份恢复工具roach逻辑备份恢复GaussDB Roach逻辑备份恢复实践                逻辑备份恢复支持、规格及约束         续备份、续恢复         逻辑备份删除         存储介质         容错支持         特殊表名         并行处理         最佳实践FAQ GaussDB Roach逻辑备份恢复原理：            1.  gs_dump逻辑备份恢复: 可以设置事务隔离级别。 gs_dump一致性备份：在单个database内保持一致，不同database之间无法保持一致，因为不同database之间需要切换connection，不能在不同database之间共享snapshot，因此只能在同一个database内保持一致性。 如果不保持一致。一个database数据量非常大，gs_dump备份时间会比较长，将会持有锁比较长的时间，对于一些需要ddl操作的database实例来说无法忍受。 解决方案：细粒度备份，而不要备份整个database，一次只备份一个table，调用gs_dump多次。如果多个表之间有关联，将这些表放入一个gs_dump操作中，用-t tablename来操作。但是这个-t其实是解决了依赖关系，本质上还是按照依赖顺序串行导出。一个单表数据量非常大，考虑分区表，也就是将数据进行了分片。否则这些表的ddl将会增加gs_dump之间的冲突。对于数据量非常大的databse实例，推荐使用PITR物理增量备份。 gs_dump并行备份: gs_dump版本>=9.3，server版本>=9.2，需要支持pg_export snapshot                                     n+1个连接，-j n是并行度，1是主节点的连接                                     对于版本<9.2，需要并行度和数据库一致性，在备份的时候不能做dml操作。             2.  roach逻辑备份恢复： GaussDB是一个分布式数据库，数据自动分片存储。GaussDB roach采用了基于单表粒度的备份恢复来实现逻辑备份，即一次只备份一个table，每次通过gs_dump导出table的ddl语句，并通过单独的外表方法（roach外表方法）来导出数据（不同表之间不保证数据一致性）。  GaussDB Roach逻辑备份恢复实践： 1. 逻辑备份恢复： 支持单表、多表（可以是不同schema的表）、schema、database级别逻辑备份。schema、database都默认转为多表逻辑执行（基于单表的串行实现），备份出schema、database内包含的所有表数据。可以从多表、schema、或者database逻辑备份中恢复出任意单张表或者多张表。 规格约束：不支持private table，nodegroup table， replication table，table has trigger/sequence表的备份恢复。                      对于表之间依赖关系，trigger，sequence，index等没有进行导出，只备份恢复数据。 单表： --tablename table  其中tablename可以是schema.table； schema默认为public，database默认为postgres单表备份：python $GPHOME/script/GaussRoach.py --master-port 9500 --agent-port 9600 --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --tablename table [--schemaname schema] [--dbname database]              单表恢复：python $GPHOME/script/GaussRoach.py --master-port 9500 --agent-port 9600 --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --tablename table [--schemaname schema] [--dbname database]  --backup-key bkpkey [--clean]/[--create] 多表： --table-list       --table-list选项与--tablename以及--schemaname不兼容；可以是不同schema中的表  tablelist文件内容示例：public.t1gauss.testT2Public."Temp"汉字表名cc.1a 多表备份：python $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --table-list tablelist [--schemaname schema] [--dbname database]              多表恢复：python $GPHOME/script/GaussRoach.py --master-port 9500 --agent-port 9600 --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --tablelist tablelist  [--dbname database]  --backup-key bkpkey [--clean]/[--create]  Schema： --schemaname  Schema规格约束： 其中系统级schema "dbms_job", "dbms_lob", "dbms_om", "dbms_output", "dbms_random", "dbms_redact", "dbms_sql", "sys", "utl_file", "utl_raw", "cstore"不支持备份恢复，都会报错退出。 Schema备份：python $GPHOME/script/GaussRoach.py --master-port port_no  --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --schemaname schema [--dbname database]              Schema恢复：python $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --schemaname schema  [--dbname database]  --backup-key bkpkey [--clean]/[--create] 其中-t restore --schemaname schema  --dbname database --backup-key bkpkey 可以从database级别逻辑备份中恢复出指定的schema Database：   --dbname        Database规格约束：其中系统级schema "dbms_job", "dbms_lob", "dbms_om", "dbms_output", "dbms_random", "dbms_redact", "dbms_sql", "sys", "utl_file", "utl_raw", "cstore"不支持备份恢复，都会被默认过滤掉。 Database备份：python $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --dbname database             Database恢复：python $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --dbname database  --backup-key bkpkey [--clean]/[--create]  2. 逻辑续备份、续恢复： 逻辑备份续备份、续恢复。其中续备份对于已经进行过校验的表名不会继续校验，以提升效率。如果在续备份时某些表已经被过滤掉，没有实际备份，而用户又对表对象属性进行了修改，希望能够得到备份，则考虑重新进行单表、多表重新备份，或者等待下次备份即可。 多表、schema、database等均支持续备份、续恢复，仅在备份、恢复失败之后才需要做。 续备份： --resume-backup --backup-key bkpkeypython $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t backup --schemaname schema [--dbname database] --resume-backup  --backup-key bkpkey 续恢复： --resume-restore--backup-key bkpkeypython $GPHOME/script/GaussRoach.py --master-port port_no --agent-port port_no --media-destination media_path  --metadata-destination metadata_path  --media-type DISK  --logging --logging-level INFO -t restore --schemaname schema  [--dbname database]  --backup-key bkpkey [--clean]/[--create] --resume-restore  3. 逻辑备份删除： 通过指定backupkey来删除，cascade是将所有backupkey全部删除。 python $GPHOME/script/GaussRoach.py --master-port port_no --media-destination /home/dulong/backup/media  --metadata-destination /home/dulong/backup/metadata  --media-type DISK  --logging --logging-level INFO -t delete --cascade  --backup-key bkpkey  4. 存储介质：一般指定DISK，兼容NBU、OBS等多种存储方式  5. 容错支持：对于不支持的表会进行过滤，不会影响其他表的正常备份恢复。 恢复到新集群：默认备份恢复database是postgres，可以指定其他database。恢复到新集群需要加--create；而恢复到老集群则最好加--clean，会将原有数据清理删除再恢复已防止数据冗余；不加则直接恢复数据，可能会导致冲突或者数据冗余。 同样的，如果一个数据库中某些表已经被drop掉，恢复时这些表需要--create，而其他表需要--clean。用--clean时恢复时另一部分需要--create的表会被过滤掉，反之亦然。  6. 特殊表名： 汉字表名不需要加双引号 大写表名，大小写表名，首字母为数字，含有$, . 等特殊字符在对象中等都为特殊对象名。其中除了含大写字符的不能自动识别外，其余均可自动识别并加上双引号。表名含有. 时，默认. 前为schema名称，如果该.就是表名的一部分，则需要加两侧加双引号，以保证可以识别正确。 特殊对象名称需要加双引号，例如schema名为 a.b，表名为 'public.'，传入必须加双引号，如‘“a.b”’，‘“public.”’,双引号外侧再加单引号是为了保证正确传入了对象名，如果传入“public.”，内部传入其实为'public.'；如果对象名内有大写字符，也需要加双引号，否则内核会默认转为小写。 PS: 尽量不要数据库对象内加各种特殊符号。  7. 并行处理： Gauss数据库为分布式数据库，默认进行了分片处理。每个数据库节点上有一个或多个datanode，一般一个datanode对应一个磁盘，而我们每个节点推荐>=2个datanode保证高可用等。数据落盘为每个datanode同时向磁盘写数据，不同datanode并行的向磁盘写入数据。 每个datanode内为串行的处理表数据，一个表数据处理完之后再处理下一个表（8.1）。在8.1及8.2后续版本中，将实现单个datanode的多个表并行的处理数据（自定义并发度）。  8. 最佳实践： 设置常规作业，利用多表逻辑备份业务中比较重要的表，schema及database备份往往将所有表备份，重要程度不高的表备份恢复仍然有较高开销。对常规作业设置优先级，按优先级进行不同时间间隔的备份与恢复。Database级别逻辑备份将备份整库数据，如果database实例内表数量大且规模大，性能会比较差（单个datanode内串行备份恢复）；推荐使用PITR物理增量备份来替代Database逻辑备份。如果逻辑备份恢复中途失败，尽可能使用续备份、续恢复以完成作业。续备份只备份未备份成功的表，且对已经校验过的表将不会进行二次校验，而现行的校验为串行校验，表数量比较大的时候开销仍然较大；续恢复将恢复未恢复成功的表。在8.1以及8.2后续版本中，将实现更为细粒度的续备份、续恢复，备份效率将更为提高。合理设置压缩算法和压缩率  FAQ：     1. Why not gs_dumpall?The  gs_dumpall program exports all databases, one after another, into a single script file, which prevents you from performing the parallel restore. If you back up all      databases this way, the restore process will take more time.The processing of dumping all databases takes longer than each individual one so you do not know which dump of each database relates to a specific point in time.              If you have a good reason to use the gs_dump all to backup all databases, the following is the command:          gs_dumpall -U postgres > c:\gsbackup\all.sql         2. Why not gs_dump?        gs_dump虽然灵活，但是数据导出按照sql或者二进制，仅支持在单节点导出。数据量较大的情况下性能往往较差，且不易扩展。      3.一致性？   数据的一致性要求在备份恢复过程中要求并不一定很高，而对于性能，扩展性，灵活性等均有一定要求。因此牺牲一定一致性来换取更好的性能，易用性等，对于实际场景往往可以接受。    

-- 使用SQL函数简单适配 CREATE OR REPLACE FUNCTION public.to_slngle_byte(str text) RETURNS text AS $$ SELECT translate(str, 'ＡＢＣＤＷＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＴＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ１２３４５４６７８９０＋－＊／．￥',  'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890+-*/.$') $$ LANGUAGE SQL; -- 如有更高性能需求，需要使用C函数实现。源码可参考开源orafce实现，具体编译方式参见DWS产品文档 -- ---- test case -- select public.to_slngle_byte('ＡＢＣＤＷＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＴＺ'); select public.to_slngle_byte('ａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ'); select public.to_slngle_byte('１２３４５４６７８９０＋－＊／．￥');

0      引子对Query执行者来说，他们的工作就是在客户端输入Query，然后翻翻报纸、喝杯咖啡就个大蒜，然后偷瞄一下执行结果是否已经返回。有时候，翻完报纸、喝完咖啡，发现数据还没有递交给我们，我们就很着急，就想知道，这家伙到底在私底下（后台）捣鼓啥呢，这么久还没给个信儿~~。于是我们就想了解下，他们到底是怎么工作的，有没有办法帮帮他们，这就需要我们了解SQL引擎和优化器的工作原理了。简单来说优化器的工作机制类似于我们常用的X德导航，定好罗马（执行目标）这个目的地，X德自动规划出N多可行路径（可实现执行目标的Path），通过各种对比计算后X德给我们推荐一条时间最短的路（执行代价最小的）。对于优化器来说执行代价最小是怎么定义的呢，答曰通过代价模型和统计信息。那么什么是统计信息、统计信息记录了什么、为什么要收集统计信息、怎么收集统计信息以及什么时候收集统计信息，且听我娓娓道来1      WHAT：什么是统计信息统计信息是指数据库描述表或数据特征的信息，常见的有表记录条数、页面数等描述表规模的信息，以及描述数据分布特征的MCV(出现频次比较高的值)、HISTOGRAM（值的数据区间分布特征）、CORRELATION（数值存储顺序与数据大小的一致性关系）等信息。本文中通过如下用例来展示统计信息是如何表现表的数据特征的DROP TABLE public.test;CREATE TABLE public.test(a int, b int, c int[]);INSERT INTO public.test VALUES (generate_series(1, 20), generate_series(1, 1200));INSERT INTO public.test VALUES (generate_series(1, 1200), generate_series(1, 1200));UPDATE public.test SET c = ('{' || a || ','|| a || '}')::int[] WHERE b <= 1000;UPDATE public.test SET c = ('{' || a || ','|| b || '}')::int[] WHERE b > 1000;ANALYZE public.test;2     WHY：为什么需要统计信息先我们看下SQL引擎从接收客户端SQL语句到执行SQL语句需要经历的关键步骤，以及各个流程中可能对执行产生影响的因素。1)  词法&语法解析按照约定的SQL语句规则，把输入的SQL语句从字符串转化为格式化结构(Stmt)，如果SQL语句存在语法错误，都会在这个环节报错。2)  语义解析语义解析类似一个翻译器，把外部输入的可视化的对象翻译为数据库内部可识别的对象（比如把Stmt中以字符串记录的表名称转化为数据库内部可识别的oid），如果语句存在语义错误(比如查询的表对象不存在)，数据库会在这个环节报错。3)   查询重写根据规则将“语义解析”的输出等价转化为执行上更为优化的结构，比如把查询语句中的视图逐层展开至最低层的表查询。4)  查询优化数据库确认SQL执行方式、生成执行计划的过程5)  查询执行根据执行计划执行SQL并输出结果的过程 整个执行流程中，优化器决定了查询语句的具体执行方式，对SQL语句的性能起着关键性的作用。数据库查询优化器分为两类：基于规则的优化器(Rule-Based Optimizer，RBO) 和基于代价的优化器(Cost-Based Optimizer，CBO)。RBO是一种基于规则的优化，对于指定的场景采用指定的执行方式，这种优化模型对数据不敏感；SQL的写法往往会影响执行计划，不了解RBO的细则的人员开发的SQL性能不可控，因此RBO逐渐被抛弃，目前GaussDB等数据库厂商的优化器都是CBO模型。CBO模型是根据SQL语句生成一组可能被使用的执行计划，并估算出每种执行计划的代价，最终选择选择一个代价最小的执行方式。数据库执行SQL语句的时候，会把执行拆分为若干步骤，如下SQLselect *from t1 join t2 on t1.a=t2.bwhere t1.b = 2 and t2.a = 3;在具体执行的时候会拆分为表扫描和表关联两个主要查询动作。这两个查询动作都存在多种执行方式，比如表扫描均存在SeqScan、IndexScan、IndexOnlyScan、BitmapScan等多种执行方式、表关联存在NestLoop、HashJoin、MergeJoin三种执行方式，那么在具体的业务场景下什么样的查询动作才是代价最小的执行方式，这就是优化器的核心工作。CBO主要工作原理是通过代价模型(Cost Model)和统计信息估算每种执行方式的代价，然后选择一种执行代价最优的执行方式。这里面代价模型是核心算法逻辑，统计信息是cost计算的数据源，二者配合完成cost计算；如果统计信息缺失，计算时代价模型会使用默认值来计算cost，当然这时cost会跟真实值存在较大偏差，大概率会出现选择非最优执行计划的情况，因此统计信息是CBO模型中 cost计算的数据输入，是CBO最核心的科技之一。3      WHERE：统计信息在哪里3.1      表规模信息系统表pg_class中的reltuples和relpages两个字段能够反映表规模信息信息，其中relpages记录了表数据存储到几个page页里面，主要用于表从存储接口扫描数据的代价计算；reltuples记录了表记录条数，主要用于扫描结果集行数估算。 查询pg_class中的表规模估算信息，显示表为2400行单表全量数据查询，通过explain查看表规模估算，显示表扫描输出行数估算为2400 3.2      单列统计信息单列统计信息是指表的单列的数据特征信息，存储在系统表pg_statistic中。因为pg_statistic会存储一些关键采样值来描述数据特征，因此pg_statistic数据是敏感的，只有超级用户才可以访问pg_statistic。通常我们推荐用户使用查询系统视图pg_stats来查询当前用户有查询权限的表的统计信息，同时pg_stats信息的可读性更强，pg_stats字段信息如下名称描述schemaname统计对象所在的namespace名tablename统计对象名attname统计列的名称inherited如果为真，那么统计分析时采样样本包括继承表数据null_frac该字段NULL值的个数比率avg_width该字段非NULL值的平均字节宽度n_distinct字段中非NULL值的distinct值。如果大于0，则表示实际distinct值个数；如果小于0，则它的绝对值表示distinct值占全部非NULL值个数比例。例如-1表示distinct值的数目与行数相同n_dndistinct第一个DN上该字段非NULL值的distinct值，取值含义与n_distinct一样most_common_vals高频非空值按照出现的频次排序的列表，列表中的值我们一般简称为MCV值most_common_freqs对应每个MCV值出现的频率列表，列表中的每个值表示对应的MCV值出现的次数与表的总记录数(包含NULL值)的比例histogram_bounds去除NULL值和most_common_vals之外的其它值按照’<’操作符排序，然后按照个数等分的边界值。如果此字段的数据类型没有<操作符或取值都在most_common_vals中出现过，则这个字段为NULLcorrelation字段值的物理行序和按照’<’排序的逻辑行序的相关性，我们一般称之为排序相关性，取值范围为-1到+1；数据越按照’<’操作符排序，取值越接近1；数据越按照’>’操作符排序，取值越接近-1。取值越接近于-1或者+1，说明索引扫描时引入的随机IO开销越小，索引扫描的随机IO的cost值也越小。如果字段数据类型没有<操作符，则这个字段为NULL。most_common_elems数组类型的最常用的非空元素的列表，类似most_common_vals，但记录的不是字段值，而是构成数组字段的元素most_common_elem_freqsmost_common_elems中每个元素出现的频次与该字段非NULL值的记录数的比例，同时还在字段尾部依次追加了元素的最小值、最大值、NULL值个数的比例，所以此字段元素的个数总是比most_common_elems元素的个数多3个elem_count_histogram数组类型非NULL distinct值的直方图信息，末尾为平均唯一值个数查询表public.test的a列的数据特征信息如下通过统计新可以看出public.test的a列的NULL值比例为0，存在120个distinct值， 1~20是MCV值，每个出现的概率是0.0254167；21~1200出现在在直方图统计信息中； 以查询语句“SELECT count(1) FROM public.test WHERE a < 44;”为例说明统计信息在优化过程中行数估算场景下的作用a)   所有MCV值均满足a < 44，所有MCV值的比例为0.0254167 * 20 = 0.5083340b)   44为直方图中第三个边界，直方图中满足a < 44的值的比例为(1-0.5083340)/100 *(3-1)= .0098333200那么表中满足a<44的tuples的个数为1243.6015680 ≈1244，通过explain打印执行计划如下 3.3      扩展统计信息扩展统计信息存储在系统表pg_statistic_ext里面，当前只支持多列统计信息这一种扩展统计信息类型。pg_statistic_ext会存储一些关键采样值来描述数据特征，因此pg_statistic_ext数据是敏感的，只有超级用户才可以访问pg_statistic_ext，通常我们推荐用户使用查询系统视图pg_ext_stats来查询当前用户有查询权限的扩展统计信息。名称描述schemaname统计对象所在的namespace名tablename统计对象名attname扩展统计信息涉及列编号的数组inherited如果为真，那么统计分析时采样样本包括继承表数据null_frac该字段组合中所有字段均为NULL值的个数比率avg_width该字段组合的平均字节宽度n_distinct字段中非NULL值的distinct值。大于零的数值是多字段组合的不同值的实际数，小于零是多字段组合的distinct值占全部非NULL值个数比例的负数n_dndistinct第一个DN上的n_distinct值most_common_vals字段组合里最常用数值的列表，此字段要求多列的每个列都不存在NULL值most_common_freqsmost_common_vals中每个值出现的频率列表，列表中的每个元素描述了most_common_vals中对应值出现的次数与表的总记录数(包含NULL值)的比例most_common_vals_null高频非空值按照出现的频次排序的列表，此字段要求多列中的至少1列包含NULL值，但又不全部是NULL值most_common_freqs_nullmost_common_vals_null中每个值出现的频率列表 表的多个列有相关性且查询中有同时基于这些列的过滤条件、关联条件或者分组操作的时候，可尝试收集多列统计信息。扩展统计信息需要手动进行收集(具体收集方法，下个小节会介绍)，如下为test表(a,b)两列的统计信息4      HOW：如何生成统计信息4.1      显式收集统计信息4.1.1 单列统计信息通过如下命令收集单列统计信息：{ ANALYZE | ANALYSE } [ VERBOSE ]  [ table_name [ ( column_name [, ...] ) ] ]; 如语法描述，我们支持对指定列做统计信息，但是实际上我们很难统计实际业务SQL中到底使用了当前哪些表的列进行了代价估算，因此建议通常情况下对全表收集统计信息。4.1.2 扩展统计信息通过如下命令收集多列统计信息：{ANALYZE | ANALYSE} [ VERBOSE ] table_name (( column_1_name, column_2_name [, ...] )); 需要注意的是，当前只支持在百分比采样模式下生成扩展统计信息，因此在收集扩展统计信息之前请确保GUC参数default_statistics_target为负数 4.2      提升统计信息质量analyze是按照随机采样算法从表上采样，根据样本计算表数据特征。采样数可以通过配置参数default_statistics_target进行控制，default_statistics_target取值范围为-100~10000，默认值为100。1） 当default_statistics_target > 0时；采样的样本数为300*default_statistics_target，default_statistics_target取值越大，采样的样本也越大，样本占用的内存空间也越大，统计信息计算耗时也越长2） 当default_statistics_target < 0时，采样的样本数为 (default_statistics_target)/100*表的总行数，default_statistics_target取值越小，采样的样本也越大。但是default_statistics_target < 0时会把采样数据下盘，不存在样本占用的内存空间的问题，但是因为样本过大，计算耗时长的问题同样存在default_statistics_target < 0时，实际采样数是(default_statistics_target)/100*表的总行，所以我们又称之为百分比采样。4.3      自动收集统计信息当配置参数autoanalyze打开时，查询语句走到优化器发现表不存在统计信息，会自动触发统计信息收集，以满足优化器的需求。以文档的case为列 注：只有对统计信息敏感的复杂查询动作(多表关联等操作)的SQL语句执行时才会触发自动收集统计信息；简单查询(比如单点，单表聚合等) 不会触发自动收集统计信息5      WHEN：什么时候收集统计信息5.1      大规模数据变化大规模数据导入/UPDATE/DELETE等操作，会导致表数据行数变化，新增的大量数据也会导致数据特征发生大的变化，此时需要对表重新收集统计信息5.2      查询新增数据常见于业务表新增数据查询场景，这个也是收集业务中最常见、最隐蔽的统计信息没有及时更新的问题，这种场景最主要的特征如下1)       存在一个按照时间增长的业务表2)       业务表每天入库新一天的数据3)       数据入库之后查询新增数据进行数据加工分析 在最后步骤的数据加工分析时，最长的方法就是使用Filter条件从分区表中筛选数据，如passtime > ‘2020-01-19 00:00:00’ AND pastime < ‘2020-01-20 00:00:00’，假如新增数据入库之后没有做analyze，优化器发现Filter条件中的passtime取值范围超过了统计信息中记录的passtime值的上边界，会把估算满足passtime > ‘2020-01-19 00:00:00’ AND pastime < ‘2020-01-20 00:00:00’的tuple个数为1条，导致估算行数验证失真6      WHO：谁来收集统计信息AP场景下业务表数据量一般都很大，单次导入的数据量也比较大，而且经常是数据导入即用，因此建议在业务开发过程中，根据数据变化量和查询特征在需要的地方主动对相关表做analyze。 

请问各位大大，使用Python3 连接 GaussDB的依赖包在哪里下载呀，如果可以的话，可以再请教一下连接步骤吗？谢谢

1.测试表及测试数据select *  from products ;     2.窗口函数row_number()（1）查询出来的数据按照price排序，并加一列序号，select type,name,price,row_number() over(order by price asc) as idx from products ;      （2）在类别(type)内按照价格(price) 升序排列(就是在类别内做排序)select type,name,price,row_number() over(PARTITION by type order by price asc) as idx from products ;rank() (1)零食类别内的 方便面和汽水价格是一样的，如何将零食和汽水并列第一SELECT type,name,price,rank() over(partition by type order by price asc) from products(2)零食类别中的第三个 辣条 排到第三了，如果这里需要在类别里面能保持序号不重不少(将辣条排名至第二)SELECT type,name,price,dense_rank() over(partition by type order by price asc) from products;

1      变更概述... 1  1.1      目的和需求... 12      变更操作步骤... 1    2.1      停止业务... 2    2.2      停止集群... 2    2.3      升级网卡驱动... 2    2.4      检查LVS配置... 2    2.5      启动集群... 3    2.6      启动业务... 3    2.7      执行gs_check巡检... 3        2.7.1生成hostfile文件... 3        2.7.2 创建工作目录... 3        2.7.3上传收集工具... 4        2.7.4分发收集工具至其他节点... 4        2.7.5执行信息收集... 5        2.7.6 分析巡检报告... 53      测试验证... 54      应急措施... 6    4.1      启停集群失败... 6    4.2      LVS检查失败... 6    4.3      gs_check巡检项未通过... 65      变更后工作... 6 5.1      变更后业务验证（必选）... 61      变更概述1.1      目的和需求保障网卡驱动升级完成后，数据库集群和客户业务稳定运行。2      变更操作步骤确保网卡驱动升级后集群运行状态正常，需按以下步骤做变更。2.1      停止业务停止SDR数据复制链路loader组件，客户操作。2.2      停止集群登录FusionInsight Manager，选择“集群 > 概览 > 停止”，点击停止按钮之后，需要输入FusionInsight Manager的密码。2.3      升级网卡驱动由硬件部门处理。2.4      检查LVS配置升级成功之后检查LVS相关配置。当LVS使用的网卡是双网卡bond时，需要关闭客户端、LVS主备节点和CN的bond网卡和物理网卡的lro、gro 、gso 、tso参数，具体如下所示（假设bond网卡名称为bond0，被bond的两个物理网卡是eth1和eth2）：查看bond网卡使用的物理网卡：ifconfig|grep `ifconfig|grep "bond0"|awk '{print $NF}'`|awk '{print $1}' ethtool -K bond0 lro gro gso tso off ethtool -K eth1 gro lro gso tso off ethtool -K eth2 gro lro gso tso off使用下面命令查看是否关闭：ethtool -k bond0 ethtool -k eth1 ethtool -k eth2显示如下信息表示lro和gro已关闭。tcp-segmentation-offload：off generic-segmentation-offload:off generic-receive-offload: off large-receive-offload: off如果lro、gro、tso、gso不能正常关闭，请联系技术支持工程师提供技术支持。2.5      启动集群检查LVS配置成功之后，启动集群。登录FusionInsight Manager，选择“集群 > 概览 > 启动”。观察集群已正常启动后进行下一步操作。2.6      启动业务启动SDR数据复制链路loader组件，客户操作。2.7      执行gs_check巡检2.7.1生成hostfile文件使用omm用户登录集群第一个CN节点执行：su - omm source     /opt/huawei/Bigdata/mppdb/.mppdbgs_profile cm_ctl query -Cvi|grep     "Primary Normal"|awk '{print$3}'|uniq > /home/omm/hostfile2.7.2 创建工作目录登录该CN节点，用omm用户执行下边命令：清理原有工作目录for i in `cat   /home/omm/hostfile`;do   ssh $i "hostname;rm -rf /home/omm/test_check"   ;done重新创建工作目录for i in `cat     /home/omm/hostfile`;do ssh $i "hostname;mkdir -p     /home/omm/test_check" ;done2.7.3上传收集工具1、确认gs_check路径，若已有gs_check工具，跳过第二步       which gs_check2、gs_check工具下载地址：     https://support.huawei.com/enterprise/zh/cloud-computing/fusioninsight-tool-pid-21624171/software  点击 FusionInsight Tool Prober 6.x.x，下载FI-mrs-syschecker-6.x.x.zip  解压后到以下目录：    SysChecker\SysCheck_C80\ClientScripts\17_MPPDB\Lib，找到gs_check3、将Check包上传至该CN节点的/home/omm/test_check目录下修改test_check目录及目录下文件的属主为ommcd /home/omm/test_check unzip Check_0330.zip chown -R omm:wheel     /home/omm/test_check/Check/ chmod +x -R   /home/omm/test_check/2.7.4分发收集工具至其他节点su - omm source   /opt/huawei/Bigdata/mppdb/.mppdbgs_profile for i in `cat /home/omm/hostfile`;do     scp -r /home/omm/test_check/* $i:/home/omm/test_check/;done2.7.5执行信息收集cd   /home/omm/test_check/Check ./gs_check -e inspect -U   omm -l   ./check.log 等待生成一下巡检结果如下： /home/omm/test_check/Check/inspection/output/CheckReport_***.tar.gz解压CheckReport_***.tar.gz得到巡检报告，如下图：将生成的巡检结果文件尽快反馈至华为工程师，需结合业务场景对巡检报告中“检查结果”列为“NG”列的巡检项进行配置指导。2.7.6 分析巡检报告客户自行分析巡检报告时，重点关注“检查结果”列为“NG”的列，对于不符合配置的，参考巡检报告最后一列“修复建议”进行修复。例如：修复网卡多队列绑定./gs_check -i CheckMultiQueue --set3      测试验证# 查集群状态cm_ctl query   -Cv4      应急措施4.1      启停集群失败分析日志，处理失败原因，重新尝试启停。4.2      LVS检查失败尝试多次检查LVS。4.3      gs_check巡检项未通过将报告及时反馈华为工程师，客户自行分析时参考gs_check巡检报告进行修复，有问题请及时联系华为工程师。5      变更后工作5.1      变更后业务验证（必选）l  集群状态检查       cm_ctl query –Cvl  客户接入业务自行测试。

目录【问题描述】【分析过程】【问题根因】【闭环方案】【恢复方案】【问题描述】1、集群FI界面显示以下告警：文件句柄使用率超过阈值、TCP临时端口使用率超过阈值等； 2、业务无法正常执行，连接DataNode5以外节点cn_5001执行作业报dn_6001_6002达到最大连接数；3、连接DataNode5上cn_5005执行作业报临时资源不可用。【分析过程】1、TCP临时端口使用率超过阈值GaussDB A支持随机端口复用，临时端口使用超过65535不会影响业务，因此此告警不会导致问题。 2、文件句柄使用率超过阈值1）查看DataNode5机器的os系统日志，搜kernel关键字，如下：localhost:~ # grep kernel /var/log/messages Jul 12 16:05:01 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:12 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:13 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 12 16:05:14 DataNode5 kernel: VFS: file-max limit 640000 reached Jul 13 09:51:46 DataNode5 kernel: VFS: file-max limit 640000 reached omm@localhost:~ #2）查操作系统配置的最大文件句柄数localhost:~ # sysctl -p|grep file-max fs.file-max = 6400003）统计进程使用句柄数情况localhost:~ # lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more由于文件句柄较多，统计较慢4）统计gaussdb各进程使用的文件句柄# 查找gaussdb进程 ps ux # 查看某个进程使用的文件句柄数 ls /proc/pid/fd | wc -l# 结果排查，发现cn（此cn为cn_5005）进程所占的文件句柄数最多，如下图，达到57万，略有异常，继续分析。5） 排查cn_5005日志，重点关注7月12号下午16:05的日志信息，如下，“remaining connection slots are reserved for non-replication system admin connections”和“dn_6037_6038: sorry, too many clients already, active/non-active: 5/2995.”均表明当前系统连接数已经达到设置的最大max_connections，不能在建连。继续确认进程启动时间并与客户确认，上一次重启时间为19年12月，8.0之前的版本，客户持续运行7个月以上，连接数可能会一直增大，这时需要用户手动执行clean connection to all for database dbtest;去清理空闲连接，否则继续建连会出现上述报错提示，且也会由于连接数太多占用内存导致执行时报临时资源不可用。疑问：客户集群共部署4个CN节点，且采用LVS负载均衡，正常情况下，LVS会将作业均衡的分发给每个CN节点，但目前只有datanode5节点报文件句柄数达到最大？？6）继续排查其它机器所占用的文件句柄数，如下图只有12万+，怀疑可能是LVS异常。7）与客户对齐发现，客户在使用LVS过程中，跑大量insert语句，刚开始运行时，观察每个cn上都会运行insert语句，运行到10小时之后（20小时才能跑完），LVS只往某两个cn上下发作业，这会导致上述cn_5005连接数远远大于其他节点。【问题根因】连接数太多导致系统业务报错【闭环方案】客户反馈近期会升级到8.0版本，8.0版本已加入自动清理空闲连接操作，不会再出现此类报错。【恢复方案】法一：清理空闲连接：clean connection to all for database dbtest;法二：集群重启后恢复

概要本篇主要讲解GaussDB使用过程中遇到的“FATAL:  terminating connection due to administrator command”相关报错进行阐述。按报错现象可分为两类场景，一类是在客户端报错的同时，查找cn日志相应时间点的日志，可以找到相关报错日志；另一类是客户端报错，但cn日志在报错时间点未能找到相关报错日志。接下来分别以这两种场景进行以案例的形式进行介绍介绍。（后续有其他场景或案例会持续补充更新）目录【场景一： CN在客户端报错相应时间点有日志记录】【问题描述】【分析过程】【闭环方案】【场景二： CN在客户端报错相应时间点未找到日志记录】【分析及案例】【场景一： CN在客户端报错相应时间点有日志记录】【问题描述】 业务偶现报错“FATAL:  terminating connection due to administrator command”，如下图：    【分析过程】业务报错打印“FATAL: terminating connection due to administrator command”, 经过排查代码只有在收到SIGTERM信号时打印此信息。进一步分析SIGTERM信号只有3个场景会触发：（1）集群停止shutdown；（2）强制清理连接clean connection force；（3）调用终止服务线程函数pg_terminate_backend(pid)三种场景详细分析如下：第一种情况：集群停止shutdown场景，分析全量日志，查看报错时间点是否有任何集群停止命令对应日志，若没有排除集群停止shutdown导致服务线程终止因素。# grep -nr "fast shutdown request" ./第二种情况：强制清理连接clean connection force，通过排查数据库各模块代码，在数据库内没有任何调用此接口的代码，只是一个对外接口，排除数据库内部自行调用clean触发因素。第三种情况：调用终止服务线程函数pg_terminate_backend(pid)，通过排查各模块代码，数据库内部有且仅有cm_agent模块一处调用。        cm_agent在检测磁盘超过阈值（默认90%）场景下，会调用命令“select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10”终止当前CN上所有非omm用户的SQL，同时打印调用日志“cancel session ok”，排查cma日志，报错时间点是否出现过cma终止当前cn所有非omm用户sql的打印。并未发现日志打印，说明cma并没有发送终止命令。# grep "pg_terminate_backend" cm/*/*.log·   目前为止遇到的此报错大多数是由于客户端调用pg_terminate_backend和clean connection foece导致，当用户遇到此类问题时，排除集群停止shutdown导致服务线程终止因素，建议排查执行的作业是否包含pg_terminate_backend和clean connection foece关键字，以下通过两个案例简单说明。·   案例详解·         案例一：1、  报错现象：客户跑批时sql被无故杀掉，业务报错打印“FATAL: terminating connection due to administrator command”2、  在日志中查看到，有关于pg_terminate_backend调用的记录(如下图)         3、  另外，CM在检查磁盘空间超过阈值设置只读时，也会下发pg_terminate_backendBDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-26 22:12:28.502 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.  BDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-27 20:14:47.912 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.  BDP17189/logfiles/cm/cm_agent/cm_agent-2019-08-06_111323-current.log:2019-10-29 04:08:51.278 tid=127209 LOG: exec: (select pg_terminate_backend(pid) from pg_stat_activity where usesysid <> 10), cancel session ok.4、  因此从日志来看，业务侧确实有调用pg_terminate_backend杀线程， 另外cm在检查磁盘空间超过阈值设置只读时也下发过几次pg_terminate_backend·         案例二：    1、报错现象：    客户端偶现报错：                2、分析    1）根据上述报错场景分析，排除集群停止shutdown，怀疑可能是调用了clean connection force和pg_terminate_backend，gdb抓现场，设置两个断点断点：pg_terminal_backend和clean_connection force。(gdb) bt #0  CleanConnection (stmt=0x7f62118aa468) at poolutils.cpp:274 #1  0x0000000001875f35 in standard_ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true,     dest=0x7f62118aa580, sentToRemote=false, completionTag=0x7f61d95648a0 "") at utility.cpp:6498 #2  0x0000000001886098 in pgaudit_ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true,     dest=0x7f62118aa580, sentToRemote=false, completionTag=0x7f61d95648a0 "") at auditfuncs.cpp:1240 #3  0x000000000186803e in ProcessUtility (parsetree=0x7f62118aa468, queryString=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", params=0x0, isTopLevel=true, dest=0x7f62118aa580,     sentToRemote=false, completionTag=0x7f61d95648a0 "") at utility.cpp:1506 #4  0x00000000018637c9 in PortalRunUtility (portal=0x7f62118af060, utilityStmt=0x7f62118aa468, isTopLevel=true, dest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1682 #5  0x0000000001863c2c in PortalRunMulti (portal=0x7f62118af060, isTopLevel=true, dest=0x7f62118aa580, altdest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1842 #6  0x0000000001862522 in PortalRun (portal=0x7f62118af060, count=9223372036854775807, isTopLevel=true, dest=0x7f62118aa580, altdest=0x7f62118aa580, completionTag=0x7f61d95648a0 "") at pquery.cpp:1114 #7  0x000000000184c22b in exec_simple_query (query_string=0x7f62118a9060 "CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres;", messageType=QUERY_MESSAGE, msg=0x7f61d9564ba0) at postgres.cpp:2777 #8  0x0000000001857110 in PostgresMain (argc=1, argv=0x7f624818f850, dbname=0x7f62437418a8 "database_resource_monitor", username=0x7f6243741840 "user_resource_monitor") at postgres.cpp:8268 #9  0x000000000166bcd3 in BackendRun (port=0x7f61d95661c0) at postmaster.cpp:7063 #10 0x000000000166d743 in SubPostmasterMain (argc=3, argv=0x7f61d9566430) at postmaster.cpp:7810 #11 0x000000000166c8f7 in MainStarterThreadFunc (args=0x7f625ad01bd8) at postmaster.cpp:7250 #12 0x0000000001d67ae6 in ThreadStarterFunc (arg=0x7f625ad01bc0) at gs_thread.cpp:389 #13 0x00007f633bf97806 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f633bcf264d in clone () from /lib64/libc.so.6 #15 0x0000000000000000 in ?? () (gdb) p *MyProcPort $1 = {sock = 212, …, remote_host = 0x7f2e6074aee0 "100.185.178.233", remote_hostname = 0x7f2e6074aee0 "100.185.178.233", remote_hostname_resolv = 0, remote_port = 0x7f2e6074af70 "52563", …}    2）由上知，对端100.185.178.233，端口41684 ，明确对端信息后，登录到对端查看此连接对应的对端进程到底在做什么    3）登录到对端机器100.185.178.233，根据remote_port 52563找到进程，结果如下图：    linux178233:/lvs_kehuduan/script/dml # netstat -anop | grep 52563    tcp        0      0 100.185.178.233:52563   100.185.185.182:6000    ESTABLISHED 229505/gsql         keepalive (1.40/0/0)    linux178233:/lvs_kehuduan/script/dml # ps ux | grep 229505    root     229505  0.7  0.0  53048  3400 pts/1    S    22:07   0:00 gsql -d database_resource_monitor -p 6000 -U user_resource_monitor -W           -h 100.185.185.182 -f dml/test_clean_connection.sql    root     229531  0.0  0.0   5736   816 pts/4    S+   22:08   0:00 grep 229505    linux178233:/lvs_kehuduan/script/dml #        3、结论    最终发现是用户在100.185.178.233 上通过gsql连接到集群，并持续执行test_clean_connection.sql，就是下图一个神奇的脚本，接近无限循环清理连接。。    一直在执行test_clean_connection.sql：--创建jack用户。 CREATE USER jack PASSWORD 'Bigdata123@'; --删除数据库template1在dn1和dn2节点上的连接。 CLEAN CONNECTION TO NODE (dn_6001_6002) FOR DATABASE template1; --删除用户jack在dn1节点上的连接。 CLEAN CONNECTION TO NODE (dn_6001_6002) TO USER jack; --删除在数据库postgres上的所有连接。 CLEAN CONNECTION TO ALL FORCE FOR DATABASE postgres; --删除用户jack。 DROP USER jack;案例三：    1.客户业务从172节点的cn接入    2.用户业务偶现报错打印“FATAL: terminating connection due to administrator command“，重试可成功    2.根据以上报错场景分析，排除shutdown场景，此报错只有两种场景：1）外部调用pg_terminate_backend函数 2）clean connection force    3.排查发现用户自己有杀超时语句的程序，但是在172节点客户程序的日志中未找到该语句被杀的记录，并且语句是刚跑起来就被杀    4.继续排查，在171节点的客户程序日志中找到了该语句被杀的日志    5.经分析，是因为客户杀语句的程序使用了current_time() - backend_start【闭环方案】    排查代码中下发SIGTERM信号场景，后续版本中在调用pg_terminate_backend和clean connection force时，均打印日志，例如：    Send SIGTERM to thread:    send SIGTERM signal to walreceiver thread    use pg_terminate_backend to terminate backend thread,tid【场景二： CN在客户端报错相应时间点未找到日志记录】    【分析及案例】    1、报错现象    Jdbc客户端报错如下：        2、分析    1）CN和DN日志中均未搜到“FATAL: terminating connection …”报错信息。按照场景一种提到的三种方式排查，均为发现异常。    2）查看用户设置的session_timeout为1d，当达到超时时间时，集群会自动关闭此连接，如下图，在11:24时重新执行作业报错，查看日志发现在11:18:54.387因为已经达到超时时间，连接已经被关闭。        3、对于jdbc来说，客户端和cn的之间的连接达到了session_timeout被kill，但是getConnections又从jdbc连接池拿了这个连接所以报的错。

A. 背景：客户在使用DWS时，经常会出现执行一个sql很久不返回结果，导致业务性能低下，从而报障。现象：一个业务sql执行很久不出结果定位方法：DWS在经常变化的表需要定期做统计优化查询，具体场景如下：1 经常变化的表，如果经常insert语句到表中，需要做analyze 表，具体语句为Analyze tablename;2 经常变化的表，如果经常删除delete数据，需要做valcumm full 表，具体语句为Valcumm full tablename 注：执行valcumm full 语句时注意不能有其他任务在跑。 注：定位技巧：查询表大小select * from pg_size_pretty(pg_table_size('tablename'));详情请点击博文链接：https://bbs.huaweicloud.com/blogs/171920

   PostGIS为PostgreSQL提供了空间数据库分析能力，是目前业界主流的地理数据库之一，提供如下空间信息服务功能：空间对象、空间索引、空间操作函数和空间操作符等。在GaussDB 中，目前已支持PostGIS地理数据库扩展，并已广泛应用于国内外安防、农业、安平等政企客户。https://bbs.huaweicloud.com/blogs/190410

第二期活动——大厂面试必备：PB级数据仓库性能调优来了，它来了，没错，继第一次之后，他又来了！本次直播干货多多，老师不仅讲解理论，做了分析，还有实际操作环节，结合具体示例进行了代码级别的详细展示，分享了很多华为云自研PB级数据仓库的特色及优势，以及，结合了具体的业务场景分享了一些通用的调优手段和性能问题方法，在此分享一下观看直播的心得以及收获。首先了解了GaussDB分布式架构，这个主要是做下简单的介绍，让第一次来的小伙伴了解一下。大体架构如图所示哦：在这个节点收到业务请求之后，会做解析和规划，然后下发任务，大体有如下模块组成，这些在上面的图中都有说明介绍的，而且进行了关系的简单梳理，方便大家了解记忆，PPT做的很贴心呀。OM：运维管理模块（Operation Manager）提供日常运维、配置管理的管理接口、工具；CM：集群管理模块（CluSter Mgnager)管理和监控分布式系统中各个功能单元和物理资源的运行情况，确保整个系统的稳定运行；Coordinator：整个系统的业务入口和结果返回;接收来自业务应用的访问请求;分解任务并调度任务分片的并行执行；GTM：全局事务控制器（Global Transaction Manager）提供全局事务控制所需的信息，采用多版本并发控制MVCC机制；WLM：工作负载管理器（Workloed Manager）控制系统资源的分配，防止过量业务负载，对系统的冲击导致业务拥塞和系统崩溃；Data Node：执行查询任务分片的逻辑实体。重头戏是关于如何优化的，提高效率。数据库优化的基本准则是“资源利用最大化”；而资源主要是指CPU、内存、磁盘IO、网络IO这四种资源。所有的调优手段都是围绕资源使用开展的。简而言之，就是将尽最大可能“压榨”资源，发挥资源的硬件极限性能。资源利用最大化有两层含义：1. SQL语句应当尽量高效：用最小的代价实现指定目标，比如点查询索引扫描要比顺序扫描代价更小。2. SQL语句应当充分利用资源：在没有资源瓶颈的情况下单一的SQL语句要尽量用更多的资源去执行，以此来提高效率。没错，就是这张PPT的主要内容：那么该如何进行调试优化呢？下面就是调优的基本流程了：调优可分为静态调优和执行态调优两部分哦！根据具体执行业务的不同时间可以分为两个阶段，首先是静态调优，通过定制化设计优化来达到我们想要的最佳的性能。如果未没有达到性能预期，则需要分析瓶颈原因，并通过调整参数等手段，再进行优化设计，这也就是第二种执行态调优。具体过程在老师的PPT中有详细的介绍，可以看看。最后，就是实际操作案例讲解了，以实际的实例作为分析的对象，从代码讲到应用，并做了简单的操作时间，真是很棒了！通过这次学习，学习到很多，了解了调优的基本原则，学习了调优过程和基本方法，更是通过实际操作进行了巩固，感觉收获满满，谢谢老师和小姐姐的分享！下次还来哦！

架构原理Cassandra旨在处理多个节点之间的大数据工作负载且无单节点故障。Cassandra通过在同构节点之间采用p2p分布式系统来解决故障问题，其中数据分布在集群中的所有节点上。通过点对点Gossip通信协议，集群中的每个节点与其他节点频繁交换状态信息。每个节点上都有一个顺序写入的commit log用来记录写入操作，以确保数据实现持久化。然后将数据编入索引并写入内存结构，称为内存表（memtable），类似于回写缓存。当内存结构写满数据时，则把数据存储到SSTable数据文件中的磁盘。所有的写入操作会在整个集群中自动分区和备份。Cassandra通过一个称为压缩（compaction）的过程定期整合SSTable，丢弃标记为删除的旧数据。为确保整个集群中所有数据的一致性，采用了各种修复机制。Cassandra是一个分区式行存储数据库，行被组织成具有所需主键的表。Cassandra架构允许任何授权用户连接到任一数据中心的任一节点，并使用CQL语言访问数据。为了方便使用，CQL使用与SQL类似的语法并与数据表一起使用。开发者可以通过cqlsh访问CQL。通常，对于由不同表组成的应用程序，一个集群对应一个密钥空间。客户端读写请求可以发送到集群中的任一节点。当客户端连接到有请求的节点时，该节点用作该客户端的协调器（coordinator）。作为客户端应用程序和被请求数据所在的节点之间的代理，协调器根据集群的配置确定环（ring）中的哪些节点应该获得请求。关键组件l  GossipGossip是用于发现和共享关于Cassandra集群中其他节点的位置和状态信息的p2p通信协议。每个节点将Gossip信息持久化到本地，以便在节点重新启动时使用该信息。l  Partitioner分区器Partitioner分区器用于确定哪个节点将接收到数据的第一个副本，以及如何在集群中的其他节点上分发其他副本。每一行数据都由主键唯一标识，该主键可以与其分区键相同，但也可以包括其他集群列。分区器是一个散列函数，从一个行的主键派生出一个令牌（token）。分区器使用令牌值来确定集群中的哪些节点接收该行的副本。Murmur3 Partitioner是新Cassandra集群的默认分区策略，在多数情况下，也是新集群的正确选择。您必须设置分区器并为每个节点分配一个num _ tokens值。令牌数量取决于系统的硬件能力。如果不使用虚拟节点（vnode），使用initial _ token设置即可。l  复制因子跨集群的副本总数。复制因子1意味着一个节点上的每一行只有一个副本。复制因子2表示每行有两个副本，每个副本在不同的节点上。没有主副本，所有副本同样重要。您可以为数据中心设置复制因子的个数。一般情况下，设置复制策略大于1，但不要超过集群中的节点数量。l  副本放置策略Cassandra将数据的副本存储在多个节点上，以保证可靠性和容错性。复制策略决定将副本放置在哪些节点上。推荐使用NetworkTopologyStrategy，以便将来扩展到多个数据中心。创建密钥空间（keyspace）时，必须确定副本放置策略和需要的副本数量。l  SnitchSnitch将机器组划分到数据中心和机架（拓扑），复制策略根据拓扑结构放置副本。创建集群时必须配置snitch。所有的snitch都使用一个动态snitch层用来监控性能并选择最佳的副本读取数据。默认情况，snitch为开启状态，推荐在大多数部署中使用。您需要在Cassandra.yaml配置文件中配置各节点的动态snitch阈值。默认情况下，SimpleSnitch不识别数据中心或机架信息，用于单个数据中心部署或公有云中的单个区域。对于生产环境，推荐使用GossipingPropertyFileSnitch，它定义了节点的数据中心和机架的信息，并通过gossip将此信息传播到其他节点。l  cassandra.yaml配置文件用于设置集群的初始化属性、表的缓存参数、调优和资源利用率、超时设置、客户端连接、备份和安全性的主要配置文件。l  系统键空间表属性可以以编程方式或使用客户端应用程序（如CQL）在每个键空间或表基础上设置存储配置属性。