第二期活动——大厂面试必备：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;       

业务侧提交了一个存储过程， 过程中有对数据进行插入的作业， 执行出现报错：numeric field overflow ·报错只有该打印，没有详细的信息，如下：无法定位到具体是哪条数据导致了该问题。cn日志里没有详细的报错信息，dn日志里可以找到具体报错的行，但是业务侧无法访问后台，查找日志不方便，希望在报错中就打印出对应的问题数据。可以使用pg_exception_context打印具体报错，如下：create or replace procedure proasdeclarev_context TEXT;begininsert into tn select * from t;exceptionwhen others thenget stacked diagnosticsv_context = pg_exception_context;dbms_output.put_line(SQLCODE);dbms_output.put_line(SQLERRM);dbms_output.put_line(v_context);end/出现报错时，可以打印出异常的数据行：

DWS中使用analyze语句可收集与数据库中表内容相关的统计信息，统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据，以生成最有效的执行计划。建议在执行了大批量插入/删除操作后，例行对表或全库执行analyze语句更新统计信息。通过以下语句可以找出数据库中哪些语句没有统计信息，并生成执行脚本：SELECT 'analyze ' || '"' || n.nspname || '"' || '.' || '"' || c.relname || '";'  FROM pg_class c  LEFT JOIN pg_namespace n    ON n.oid = c.relnamespace WHERE c.relkind = 'r' ::"char"   and pg_stat_get_last_analyze_time(c.oid) is null   and c.oid > (16384 - 1);示例：对一张表执行analyze后，再次查询如下：

DWS中有两种情况需要关注表是否做过update及delete操作：（1）对表频繁做update或者delete操作会产生大量的磁盘页面碎片，从而逐渐降低查询的效率，需要将磁盘页面碎片回复并交换操作系统，即vacuum full 操作，这时候需要找出那些表做过update；（2）判断一张表是否是维度表，是否可以从Hash表变更为复制表，可以查看这张表是否做过update或delete,如果做过update或delete操作，则不可以修改为复制表；可以通过以下脚本找出那些表做过update及delete操作：analyze +tablename;SELECT      n.nspname , c.relname,     pg_stat_get_tuples_deleted(x.pcrelid) as deleted,pg_stat_get_tuples_updated(x.pcrelid) as updatedFROM pg_class cINNER JOIN pg_namespace n ON n.oid = c.relnamespaceINNER JOIN pgxc_class x ON x.pcrelid = c.oidWHERE c.relkind = 'r' and c.relname='tablename' ;eg：

（1）前提条件：GUC参数enable_resource_track为on （默认为on）GUC参数resource_track_level为query或operator（默认为query）GUC参数enable_resource_record为on（默认为off）GUC参数resource_track_duration小于作业执行时间（默认为60s）（2）创建统计函数：CREATE OR REPLACE FUNCTION public.stream_count(text)         RETURNS integer         LANGUAGE sql         IMMUTABLE STRICT NOT FENCED NOT SHIPPABLE      AS $function$           select ((length($1) - length(replace(replace($1, 'Streaming(type: B', ''), 'Streaming(type: R', ''))) / length('Streaming(type: B'))::int      $function$ CREATE OR REPLACE FUNCTION public.subplan_count(text)         RETURNS integer         LANGUAGE sql         IMMUTABLE STRICT NOT FENCED NOT SHIPPABLE      AS $function$         select ((length($1) - length(replace($1, 'SubPlan', '')) )::int / length('SubPlan'))::int      $function$（3）TopSql 历史数据数据转储表：create table topsql_xxxxxxxx DISTRIBUTE BY HASH(queryid) as select t.dbname,t.count,t.avg_duration,t.count*t.avg_duration as totaltime,t.max_duration,t.stream_count,t.subplan_count,t.queryid,p.query,p.query_plan from (selectsubstr(query,1,60) as sub_query, dbname, count(1) as count,round(avg(duration),2) as avg_duration,max(duration) as max_duration,public.stream_count(query_plan) as stream_count,public.subplan_count(query_plan) as subplan_count,max(queryid) as queryidfrom pgxc_wlm_session_infowhere dbname = 'database'and start_time >'xxxx-xx-xx xx:xx:xx'and finish_time < 'xxxx-xx-xx xx:xx:xx'group by 1,2,6,7having (count >0  ) )t left join pgxc_wlm_session_info p on t.queryid = p.queryid;（4）导出到csv文件copy (select * from topsql_xxxxxxxx) to '{filepath}/topsql_xxxxxxxx.csv' with(format 'csv',header 'on',encoding 'gbk');说明：上述SQL中标红的内容需根据现场情况修改：dbname ：待抓取TopSql的数据库start_time ：抓取记录开始时间finish_time：抓取记录截止时间

        GaussDB for DWS时分布式框架，支持两种分布方案：分布方式描述适用场景Hash 表数据通过Hash方式散列到集群中的所有DN上。数据量较大的事实表。Replication集群中每一个DN都有一份全量表数据。维度表、数据量较小的事实表。在表设计时应尽量避免数据shuffle。shuffle，是指在物理上，数据从一个节点，传输到另一个节点。shuffle占用了大量宝贵的网络资源，减小不必要的数据shuffle，可以减少网络压力，使数据的处理本地化，提高集群的性能和可支持的并发度。Hash表数据分布在各个DN上，在进行关联查询时，如果关联字段无法作为分布列字段，则会产生shuffle，因此对于维度表、数据量较小的事实表，使用复制表减少参与计算的线程数和减少网络数据交互，提升查询性能。eg:hash表执行计划如下：复制表改造前有stream算子，单条语句执行时间670.56ms。把功能科目的基础数据表fasp_t_pubexpfunc改成复制表后，执行计划中没有stream算子，执行时间提升为534.53ms。在并发场景下，对于小表来说，stream的压力是主要瓶颈，把hash表改成复制表，并发场景下性能提升明显。

1.GaussDB For DWS中测试结果：（1）定义一个表t1及视图v1，t1表插入数据：create table t1(a int);create view v1 as select * from t1;insert into t1 values(1);（2）t1表rename为t2表alter table t1 rename to t2;（3）查询视图v1定义及数据select * from v1;select pg_get_viewdef('v1');如上图，在DWS中，视图依赖的表发生rename后，变更的表名会同步至视图定义。1.Oracle中测试结果：（1）定义一个表t1及视图v1，t1表插入数据create table t1(a int);create view v1 as select * from t1;insert into t1 values(1);（2）t1表rename为t2表alter table t1 rename to t2;（3）查询视图v1定义及数据select * from v1;select dbms_metadata.get_ddl('VIEW','V1') from dual;如上图，在Oracle中，视图依赖的表发生rename后，变更的表名不会同步至视图定义。

问题背景与现象安装双机oms，主oms安装成功，安装备oms时报启动ntp超时。原因分析在主备oms上分别执行sh /opt/huawei/Bigdata/om-0.0.1/sbin/status-oms.sh，如果看不到对端oms状态信息，基本可以确认是HA证书过期导致。可通过下面命令查看证书的有效时间以及系统当前时间（GMT时间可以等效于UTC时间）。openssl x509 -in /opt/huawei/Bigdata/om-0.0.1/security/certHA/root-ca.crt -noout –dates。可以看到系统当前时间已经超过证书有效期，可以确定是HA证书过期导致。解决办法使用omm用户在主OMS节点上执行以下命令生成证书私钥（安装场景root安装可以使用root用户执行，非root安装则该步骤可放在执行preset之后）：openssl genrsa -aes256 -passout pass:$password -out $path/root-ca.pem 2048其中$password为证书密码，$path为存放私钥和证书文件的路径，下同。例如：openssl genrsa -aes256 -passout pass:Changeme_123 -out /home/omm/root-ca.pem 2048生成root-ca.pem（如果是升级/新安装场景，务必保证 $password是FI证书的默认密码Changeme_123）。使用omm用户在主OMS节点上执行以下命令生成证书（安装场景root安装可以使用root用户执行，非root安装则该步骤可放在执行preset之后）：openssl req -passin pass:$password -new -x509 -days $days -key $path/root-ca.pem -sha256 -out $path/root-ca.crt -subj "/C=$country/ST=$state/L=$city/O=$company/OU=$organize/CN=$commonname/emailAddress=$email"其中，$password为生成私钥时传入的密码，$days为证书的有效期天数，$path为临时存放证书的路径，均可根据实际需要进行配置。例如：生成证书openssl req -passin pass:Changeme_123 -new -x509 -days 36500 -key /home/omm/root-ca.pem -sha256 -out /home/omm/root-ca.crt -subj /C=CN/ST=guangdong/L=shenzhen/O=huawei/OU=IT/CN=HADOOP.COM/emailAddress=FI@huawei.com这样，就在 /home/omm目录下生成了root-ca.crt和root-ca.pem两个文件。使用安装/升级用户进入到升级/安装包解压后的安装目录(假定用户已经将升级/安装包解压)；cd升级(安装)包所在目录/FusionInsight/software/om/package解压缩om-0.0.1.tar.gz，执行下列命令：tar -zxvf om-0.0.1.tar.gz替换预置的HA证书。手工将上面步骤1中生成的root-ca.crt和root-ca.pem拷贝到解压缩后的om-0.0.1/security/certHA/目录下，替换掉目录下原有文件，注意文件权限不变。替换完成后，重新压缩om-0.0.1.tar.gz，注意重新压缩后权限不变。cd升级包(安装包)所在目录/FusionInsight/software/om/packagerm -f om-0.0.1.tar.gztar -czvf om-0.0.1.tar.gz om-0.0.1rm -rf om-0.0.1操作完成以后，可以按照正常的流程进行升级或安装操作。

问题背景与现象安装OMS失败，提示Failed to install logman。原因分析查看安装日志“/var/log/Bigdata/controller/scriptlog/install.log”，报如下错误：[2016-06-17 09:58:35] DEBUG configDiskManager end [install.sh(configDiskManager):1997](113506)[2016-06-17 09:58:35] INFO Start oms. [install.sh(start_oms):843](113506)start HA successfully.[2016-06-17 09:59:30] DEBUG Config crontab. [install.sh(config_crontab):348](113506)[2016-06-17 09:59:30] INFO Succeed to start oms. [install.sh(start_oms):864](113506)[2016-06-17 09:59:30] INFO The script to install logman. [install.sh(install_logman):1367](113506)You (omm) are not allowed to use this program (crontab)See crontab(1) for more informationget crontab file failed.You (omm) are not allowed to use this program (crontab)See crontab(1) for more informationget crontab file failed.[2016-06-17 09:59:30] ERROR Failed to install logman. [install.sh(main):1832](113506)ERROR:Failed to install logman.[2016-06-17 09:59:30] ERROR Installation failed. For details about the error, see the log file /var/log/Bigdata/controller/scriptlog/install.log. [install.sh(post_install):443](112780)cron配置文件被修改，导致没权限修改crontab文件，导致logman安装失败。解决办法修改“cron.deny.bak”为“cron.deny”，卸载后重新安装。