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”，卸载后重新安装。 

问题背景与现象安装OMS失败。原因分析查看gaussDB安装日志“/var/log/gaussdbinstall.log”。操作系统shared_buffers参数的值大于kernel.shmmax。解决办法编辑“/etc/sysctl.conf”文件，设置“kernel.shmmax”的值，格式如下。kernel.shmmax = value建议将shmmax的值设置为物理内存大小的一半。可用如下命令查看本机的物理内存：grep MemTotal /proc/meminfo显示类似如下的信息：MeMTotal: 6088240 kB则kernel.shmmax的大小可设置为6088240*1024/2=3117178880。kernel.shmmax = 3117178880执行如下命令，使SUSE Linux启动时自动读取内核参数。/sbin/chkconfig boot.sysctl on执行如下命令使内核参数生效。/sbin/sysctl -p 

问题背景与现象安装OMS失败。原因分析查看“/var/log/Bigdata/omm/oms/install_oms.log”。手动执行报错的命令：可以看出是root用户的属组不对。解决方法修改root用户属组id为0，重新安装OMS。