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）在每个键空间或表基础上设置存储配置属性。

7月20日，华为云在TechWave技术峰会上正式发布了GaussDB系列新品，数据库战略全面升级，进一步满足政企客户业务需求，持续加速客户数字化转型进程。华为云数据库业务总裁苏光牛表示：“华为将持续战略投入数据库，布局全球7大区域囊括1000+数据库专家与人才。此次战略升级是华为云数据库积极构建高安全、高可靠、高性能的全场景云服务，拥抱开源生态的具体举措，华为云GaussDB数据库会持续打造多元生态服务，全方位满足客户的需求，加速政企客户数字化创新发展。”华为云数据库战略全面升级苏光牛表示，数据库是信息产业三个核心控制点和基础研究之一（硬件芯片、软件数据库与操作系统），也是华为鲲鹏计算产业与华为云的重要组成部分，同时也是支持华为内部业务正常运作并持续服务全球客户的数据底座不可或缺的关键组成。华为将继续战略投入，打造世界级数据库，保障业务连续性并为客户持续提供数据库服务。基于打造更好更丰富的数据库服务，华为云数据库在品牌和业务方面也进行了全面升级，华为云GaussDB重点打造涵盖关系型与非关系型在内的GaussDB系列全场景云服务，依托华为云与华为云Stack，以云服务方式持续为客户服务，提升交付与运维效率，帮助客户聚焦核心业务创新，快速提供创新技术和新服务。 华为云GaussDB系列新品商用发布华为云GaussDB是华为基于在电信、政企市场深耕10年+的数据库内核研发优化能力、对客户高可靠高性能诉求的理解，结合云的技术倾力打造的企业级分布式数据库。GaussDB将陆续推出兼容主流开放生态如MySQL等数据库服务和基于华为openGauss开源生态的GaussDB商业版本，满足政企客户高性能、高可靠、高安全的全场景数据库服务，开启数据库极速融合时代，加速政企智能升级。发布会上，华为云重磅推出了关系型数据库GaussDB（for MySQL）和非关系型数据库GaussDB NoSQL系列两大云原生数据库新品。GaussDB(for MySQL)基于华为最新一代DFV分布式存储，采用计算存储分离架构，支持1写15读的只读节点的极速扩展，最高支持128TB的海量存储，可实现超百万级QPS吞吐，单节点相比原生MySQL性能提升7倍，业界第一。GaussDB NoSQL拥有极强的多模数据管理能力，在并发读写能力、扩容时间缩、故障重构时间、备份效率、恢复效率等方面也都实现业界领先。华为云数据库还提供统一管控平台和接口，实现多业务数据融合，支撑多样化的应用服务。 华为云GaussDB系列数据库产品涵盖关系型和非关系型数据库场景，广泛应用于金融，泛政府、电信、能源、交通、医疗、物流、电商等行业，能满足客户对智能时代高并发事务实时处理、海量数据高效分析等全方位需求，持续加速客户数字化转型进程。目前GaussDB(for MySQL)、GaussDB(for Mongo)、GaussDB(for Cassandra)3款自研黑科技，现在体验优惠价6.7折起噢！活动链接：cid:link_0

简介数据持久性和服务可用性是数据库服务的关键特征。在实践中，通常认为拥有 3 份数据副本，就足以保证持久性。但是 3 份副本，对于可用性的要求是不够的。维护 3 份一致的副本意味着，这些副本必须同时在线，系统才能保证可用。当数据库跨多个节点分片时，某些节点不可用的概率会随着节点数量的增加而呈指数增长。在 GaussDB(for MySQL) 中，我们针对日志和数据采用不同副本策略，并采用一种新颖的恢复算法，来解决可用性的问题。下面首先介绍写路径，然后介绍读路径，最后分析理论上的可用性估计，并与其它副本策略进行比较。写路径写路径如上图所示，下面对每一个步骤进行说明。1）用户事务导致对数据库页面的更改，从而生成描述更改的日志记录（redo log，下面简称 redo）。2）将 redo 写入到 Log Stores。写入 3 份副本，并且采用强一致性，即 3 份均写入成功才算成功。3）将事务标记为已提交（committed）。只要集群中有三个或以上的 Log Stores 可用，该数据库就可以进行写操作（因为写入只需要选择可用的节点即可，并不规定一定要写入某个节点）。对于成千上万个节点的群集，这实际上意味着 100％ 的写入可用性。4）redo 写入 Log Stores 之后，会将此 redo 放入到 SAL 的 write buffer 中，之后将此 buffer 写入到管理对应 slice 的 Page Store 上。5）当任何一个 Page Store 副本返回成功，此写入成功，SAL 的 write buffer 被释放。6）不同的 Page Store 副本之间使用 gossip 协议检测和修复缺失的日志。空间回收数据库运行过程中，会源源不断地产生 redo 日志。如果不将不需要的 redo 删除，可以预见，最终肯定会耗尽磁盘空间。在成功将 redo 写入所有 Slice 副本，并且所有数据库的读副本（read replica）都可以看到该记录之后，就可以将该日志从 Log Store 中删除。独立地跟踪每条 redo 的持久性很费资源，因此我们选择基于 LSN 来跟踪持久性。对于 Page Store 的每个 slice，都有一个 persistent LSN，它的含义是 slice 接收到的所有日志记录中，保证连续（没有空洞）的最大 LSN。（譬如某个 slice 接收到 LSN 为 1 的 redo log 后，persistent LSN 变为 1，此时如果接收到 LSN 为 3 的 redo log，persistent LSN 依然为 1。之后如果接收到 LSN 为 2 的 redo log，即补齐了空洞之后， persistent LSN 变为 3）。7）SAL 可以通过定期调用 api 或者在读写接口中获取每个 slice 的 persistent LSN（在恢复中也会使用）。8）SAL 也会跟踪每个 PLog 的 LSN 范围。如果 PLog 中的所有 redo 的 LSN 都小于数据库 persistent LSN（3 副本中最小 persistent LSN），该 PLog 可被删除。通过上面的机制，我们能够保证每条 redo 都至少会有三个节点上存在副本（一开始在 Plog Store 节点上有 3 副本，保证在 Page Store 节点上有 3 副本之后，将 Plog Store 节点上的副本删除，以回收磁盘资源）。读路径数据库前端以 page 粒度读取数据。读取或者修改数据时，相应的 page 必须在 buffer pool 中。当 buffer pool 已满，我们又需要引入一个 page 时，必须将某些页面从 buffer pool 中淘汰。我们对淘汰算法进行了修改，保证只有当所有相关 redo 日志都写入至少 1 个 Page Store 副本后，脏页才能被淘汰。因此，在最新的 redo 记录到达 Page Store 之前，保证相应的页面可从 buffer pool 中获得。 之后，可以从 Page Store 中读取页面。对于每一个 slice，SAL 保存最新 redo log 的 LSN。主节点读取 page 时，读请求首先到达 SAL，SAL 会使用上述 LSN 下发读请求。读请求会被路由到时延最低的 Page Store。如果被选择的 Page Store 不可用或者还没有收到提供 LSN 之前的所有 redo，会返回错误。之后 SAL 会尝试下一个 Page Store，遍历所有副本，直到读请求可以被正确响应。可用性分析quorum replication目前业界最广泛使用的强一致性复制技术基于 quorum replication。如果每份数据在 N 个节点上存在副本，每个读取操作必须从NR个节点接收响应，并写入NW个节点。为了保证强一致性，必须满足 NR + NW > N 。业界许多系统使用 quorum replication 的不同组合方式。 例如，1）RAID1 磁盘阵列中通常使用 N = 3，NR = 1，NW = 3；2）PolarDB 中，N = 3，NR = 2，NW = 2；3）Aurora 中，N = 6，NR = 3，NW = 4。下面的分析中，仅考虑节点单独出现不可用的场景（不考虑譬如因为断点导致所有节点不可用的场景）。假设 1 个节点不可用的概率为 x，则当 N - NW + 1 到 N 个节点同时不可用时，写请求会失败。 即一个写请求失败的概率可用如下公式计算：同理，一个读请求失败的概率计算公式如下：GaussDB(for MySQL)写在前面的写路径一节中已经提到，GaussDB(for MySQL) 的写 redo，不需要写到特定的 Log Store 上，所以公式 (1) 并不适用。对于写请求，只有当所有 PLog Store 都不可用时，才会失败。如果集群中 Log Store 足够多，这个概率几乎接近于 0。读对于读，每个 Page Store 节点都可以基于其 persistent LSN 决定是否可以为读提供服务。如果不能，它将返回错误，告诉 SAL 尝试另一个节点。在极少数情况下，由于级联故障，没有节点可以提供读服务（并非节点不可用），SAL 会识别这种情况并使用 Log Store 来修复数据。在这种情况下，性能可能下降，但是存储层仍然可用。SAL 无法恢复的唯一情况是，包含 Slice 副本的所有 Page Store 都不可用，这样的概率是 x^3。下表对比了 GaussDB(for MySQL) 和几种典型 quorum replication 场景的可用性：结论1）对于写，GaussDB(for MySQL) 总是可用的，优于 quorum replication 方案；2）对于读，除了 x = 0.01 且 quorum 的节点个数为 6 的情况，GaussDB(for MySQL) 总是能提供比 quorum replication 相同或更好的的可用性。并且在上面的场景下，提供的可用性已经足够高，与 quorum replication  相差并不远。

查询数据库内脏页率大于0的表select * from PGXC_GET_STAT_ALL_TABLES  where dirty_page_rate>0;n_tup_ins：插入的元组条数n_tup_upd：更新的元组条数n_tup_del：删除的元组条数。n_live_tup：存活元组的条数。n_dead_tup：死亡元组的条数。page_dirty_rate：表的脏页率信息(%)。建议对脏页率超过30%的非系统表执行VACUUM FULL，用户也可根据业务场景自行选择是否执行VACUUM FULL。select 'vacuum full '||relname||';' from PGXC_GET_STAT_ALL_TABLES  where dirty_page_rate>0;执行vacuum full 及analyze后查看脏页率

# 一、数据仓库的“心脏” 首先来谈谈数据模型。模型是现实世界特征的模拟和抽象，比如地图、建筑设计沙盘，飞机模型等等。  而数据模型Data Model是现实世界数据特征的抽象。  在数据仓库项目建设中，数据模型的建立具有重要的意义，客户的业务场景，流程规则，行业知识都体现在通过数据模型表现出来，在业务人员和技术人员之间搭建起来了一个沟通的桥梁，所以在国外一些数据仓库的文献中，把数据模型称之为数据仓库的心脏“The Heart of the DataWarehouse”  数据模型设计的好坏直接影响数据的 - 稳定性 - 易用性 - 访问效率 - 存储容量 - 维护成本 # 二、数据仓库中数据模型，数据分层和ETL程序 2.1 概述 数据仓库是一种通过(准)实时/批量的方式把各种外部数据源集成起来后，采用多种方式提供给最终用户进行数据消费的信息系统。 面对繁多的上游业务系统而言，数据仓库的一个重要任务就是进行数据清洗和集成，形成一个标准化的规范化的数据结构，为后续的一致性的数据分析提供可信的数据基础。 另一方面数据仓库里面的数据要发挥价值就需要通过多种形式表现，有用于了解企业生产状况的固定报表，有用于向管理层汇报的KPI驾驶舱，有用于大屏展示的实时数据推送，有用于部门应用的数据集市，也有用于分析师的数据实验室...对于不同的数据消费途径，数据需要从高度一致性的基础模型转向便于数据展现和数据分析的维度模型。不同阶段的数据因此需要使用不同架构特点的数据模型与之相匹配，这也就是数据在数据仓库里面进行数据分层的原因。 数据在各层数据中间的流转，就是从一种数据模型转向另外一种数据模型，这种转换的过程需要借助的就是ETL算法。打个比方，数据就是数据仓库中的原材料，而数据模型是不同产品形态的模子，不同的数据层就是仓库的各个“车间”，数据在各个“车间”的形成流水线式的传动就是依靠调度工具这个流程自动化软件，执行SQL的客户端工具是流水线上的机械臂，而ETL程序就是驱动机械臂进行产品加工的算法核心。 上图是数据仓库工具箱-维度建模权威指南一书中的数据仓库混合辐射架构2.2 金融行业中的分层模型 金融行业中的数据仓库是对模型建设要求最高也是最为成熟的一个行业，在多年的金融行业数据仓库项目建设过程中，基本上都形成了缓冲层，基础模型层，汇总层（共性加工层），以及集市层。不同的客户会依托这四层模型做不同的演化，可能经过合并形成三层，也可能经过细分，形成5层或者6层。本文简单介绍最常见的四层模型： 缓冲层：有的项目也称为ODS层，简单说这一层数据的模型就是贴源的，对于仓库的用户就是在仓库里面形成一个上游系统的落地缓冲带，原汁原味的生产数据在这一层得以保存和体现，所以这一层数据保留时间周期较短，常见的是7~15天，最大的用途是直接提供基于源系统结构的简单原貌访问，如审计等。 基础层：也称为核心层，基础模型层，PDM层等等。数据按照主题域进行划分整合后，较长周期地保存详细数据。这一层数据高度整合，是整个数据仓库的核心区域，是所有后面数据层的基础。这一层保存的保存的数据最少13个月，常见的是2~5年。 集市层：先跳到最后一层。集市层的数据模型具备强烈的业务意义，便于业务人员理解和使用，是为了满足部门用户，业务用户，关键管理用户的访问和查询所使用的，而往往对接前段门户的数据查询，报表工具的访问，以及数据挖掘分析工具的探索。 汇总层：汇总层其实并不是一开始就建立起来的。往往是基础层和集市层建立起来后，发现众多的集市层数据进行汇总，统计，加工的时候存在对基础层数据的反复查询和扫描，而不同部门的数据集市的统计算法实际上是有共性的，所以主键的在两层之间，把具有共性的汇总结果形成一个独立的数据层次，承上启下，节省整个系统计算资源。  2.3数据仓库常见ETL算法 虽然数据仓库里面数据模型对于不同行业，不同业务场景有着千差万别，但从本质上从缓冲层到基础层的数据加工就是对于增/全量数据如何能够高效地追加到基础层的数据表中，并形成合理的数据历史变化信息链条；而从基础层到汇总层进而到集市层，则是如何通过关联，汇总，聚合，分组这几种手段进行数据处理。所以长期积累下来，对于数据层次之间的数据转换算法实际上也能形成固定的ETL算法，这也是市面上很多数据仓库代码生成工具能够自动化地智能化地形成无编码方式开发数据仓库ETL脚本的原因所在。这里由于篇幅关系，只简单列举一下缓冲层到基础层常见的几种ETL算法，具体的算法对应的SQL脚本可以找时间另起篇幅详细地介绍。 1. 全表覆盖A1 算法说明：删除目标表全部数据，再插入当前数据 来源数据量：全量数据 适用场景：无需保留历史路径，只使用最新状态数据 2. 更新插入(Upsert)A2 算法说明：本日数据按照主键比对后更新数据，新增的数据采用插入的方式增加数据 来源数据量：增量或全量数据 适用场景：无需保留历史路径，只使用最新状态数据 3. 历史拉链（History chain）A3 算法说明：数据按照主键与上日数据进行比对，对更新数据进行当日的关链和当日开链操作，对新增数据增加当日开链的记录 来源数据：增量或全量数据 适用场景：需要保留历史变化路径的数据，这部分数据会忽略删除信息，例如客户表、账户表等 4. 全量拉链（Full History chain）A4 算法说明：本日全量数据与拉链表中上日数据进行全字段比对，比对结果中不存在的数据进行当日关链操作，对更新数据进行当日关链和当日开链操作，对新增数据增加当日开链的记录 来源数据量：全量数据 适用场景：需要保留历史变化路径的数据，这部分数据会由数据比对出删除信息进行关链 5. 带删除增量拉链(Fx:Delta History Chain) A5 算法说明：本日增量数据根据增量中变更标志对删除数据进行当日关链操作，对更新和新增数据与上日按主键比对后根据需要进行当日关链和当日开链操作，对新增数据增加当日开链的记录 来源数据量：增量数据 适用场景：需要保留历史变化路径的数据，这部分数据会根据CHG_CODE来判断删除信息 6. 追加算法（Append）A6 算法说明：删除当日/月的增量数据，插入本日/月的增量数据 来源数据量：增量数据 适用场景：流水类或事件类数据 # 三、DWS和数据仓库 华为的DWS服务是一种基于公有云基础架构的分布式MPP数据库。其主要面向海量数据分析场景。MPP数据库是业界实现数据仓库系统最主流的数据库架构，这种架构的主要特点就是Shared-nothing分布式架构，由众多拥有独立且互不共享的CPU、内存、存储等系统资源的逻辑节点（也就是DN节点）组成。 在这样的系统架构中，业务数据被分散存储在多个节点上，SQL被推送到数据所在位置就近执行，并行地完成大规模的数据处理工作，实现对数据处理的快速响应。基于Shared-Nothing无共享分布式架构，也能够保证随着集群规模地扩展，业务处理能力得到线性增长。 

创建测试表，插入数据create table t1(a int,b text);insert into t1 values(1,'aaa'),(1,'bbb'),(2,'aaa'),(2,'bbb'),(3,'awef'),(3,'awefawef'),(4,'fwefw'),(1,'aaa');基于a字段去重select t.a,t.b from (select *, row_number() over(partition by a) as rn from t1 ) t where rn = 1;       基于a，b字段去重select t.a,t.b from (select *, row_number() over(partition by a,b) as rn from t1 ) t where rn = 1;