本文分享自华为云社区《[GaussDB(DWS)之查询时索引失效原因](https://bbs.huaweicloud.com/blogs/348498?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者： 飞不起来的小松鼠 。 使用GaussDB(DWS)时，有时为了加快查询速度，需要对表建立索引。有时我们会遇到明明建立了索引，查询计划中却发现索引没有被使用的情况。本文将列举几种常见的场景和优化方法。 ## 1. 返回结果集很大 以行存表的Seq Scan和Index Scan为例： Seq Scan：就是按照表的记录的排列顺序从头到尾依次检索扫描，每次扫描要取到所有的记录。这也是最简单最基础的扫表方式，扫描的代价比较大； Index Scan：对于给定的查询，先扫描一遍索引，从索引中找到符合要求的记录的位置(指针)，再定位到表中具体的Page去取，即先走索引，再读表数据； 因此，根据两种扫描方式的特点可以看出，大多数情况下，Index Scan要比Seq Scan快。但是如果获取的结果集占所有数据的比重很大时（超过70%），这时Index Scan 因为要先扫描索引再读表数据反而不如直接全表扫描来的快。 ## 2. 没有analyze analyze会更新表的统计信息，如果表未做analyze或上次做完analyze之后表进行过数据量较大的增删操作，会导致统计信息不准，这时候也可能导致表没有走索引。 优化方法：对表进行analyze更新统计信息即可。 ## 3. 过滤条件使用了函数或隐式类型转化导致没有走索引 如果再过滤条件中使用了计算、函数、隐式类型转化，都可能导致无法选择索引。 示例：create table test(a int, b text, c date); 且在a，b，c三列上都分别创建了索引。 **场景1：使用计算** 从下面的执行结果可以看到，where a = 101，where a = 102 - 1都能使用a列上的索引，但是where a + 1 = 102没有走索引。 ```postgres postgres=# explain verbose select * from test where a + 1 = 102; QUERY PLAN ------------------------------------------------------------------- Streaming (type: GATHER) (cost=0.19..18.25 rows=6 width=14) Output: a, b, c Node/s: All datanodes -> Seq Scan on public.test (cost=0.00..12.25 rows=6 width=14) Output: a, b, c Distribute Key: a Filter: ((test.a + 1) = 102) (7 rows) postgres=# postgres=# explain verbose select * from test where a = 101; QUERY PLAN ------------------------------------------------------------------------------------- Streaming (type: GATHER) (cost=0.06..14.27 rows=1 width=14) Output: a, b, c Node/s: datanode1 -> Index Scan using test_a_idx on public.test (cost=0.00..8.27 rows=1 width=14) Output: a, b, c Distribute Key: a Index Cond: (test.a = 101) (7 rows) postgres=# postgres=# explain verbose select * from test where a = 102 - 1; QUERY PLAN ------------------------------------------------------------------------------------- Streaming (type: GATHER) (cost=0.06..14.27 rows=1 width=14) Output: a, b, c Node/s: datanode1 -> Index Scan using test_a_idx on public.test (cost=0.00..8.27 rows=1 width=14) Output: a, b, c Distribute Key: a Index Cond: (test.a = 101) (7 rows) ``` 优化方式：此类场景的优化方式是尽量使用常量代替表达式，或者常量计算尽量写在等号的右侧。 **场景2：使用函数** 从下面的执行结果可以看到，在索引列上使用函数也会导致无法选择索引： ```postgres postgres=# explain verbose select * from test where to_char(c, 'yyyyMMdd') = to_char(CURRENT_DATE,'yyyyMMdd'); QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------- Streaming (type: GATHER) (cost=0.19..21.00 rows=6 width=14) Output: a, b, c Node/s: All datanodes -> Seq Scan on public.test (cost=0.00..15.00 rows=6 width=14) Output: a, b, c Distribute Key: a Filter: (to_char(test.c, 'yyyyMMdd'::text) = to_char(('2021-03-16'::date)::timestamp with time zone, 'yyyyMMdd'::text)) (7 rows) postgres=# postgres=# explain verbose select * from test where c = current_date; QUERY PLAN ------------------------------------------------------------------------------------- Streaming (type: GATHER) (cost=0.06..14.27 rows=1 width=14) Output: a, b, c Node/s: All datanodes -> Index Scan using test_c_idx on public.test (cost=0.00..8.27 rows=1 width=14) Output: a, b, c Distribute Key: a Index Cond: (test.c = '2021-03-16'::date) (7 rows) ``` 优化方法：尽量减少索引列上没有必要的函数调用。 **场景3：隐式类型转化** 此类场景是经常遇到的场景，例如b的类型是text类型，过滤条件是where b = 2，在生成计划时，text类型会隐式转化为bigint类型，实际的过滤条件变成where b::bigint = 2，导致b列上的索引失效： ```postgres postgres=# explain verbose select * from test where b = 2; QUERY PLAN ------------------------------------------------------------------- Streaming (type: GATHER) (cost=0.06..18.25 rows=1 width=14) Output: a, b, c Node/s: All datanodes -> Seq Scan on public.test (cost=0.00..12.25 rows=1 width=14) Output: a, b, c Distribute Key: a Filter: ((test.b)::bigint = 2) (7 rows) postgres=# postgres=# postgres=# explain verbose select * from test where b = '2'; QUERY PLAN ------------------------------------------------------------------------------------- Streaming (type: GATHER) (cost=0.06..14.27 rows=1 width=14) Output: a, b, c Node/s: All datanodes -> Index Scan using test_b_idx on public.test (cost=0.00..8.27 rows=1 width=14) Output: a, b, c Distribute Key: a Index Cond: (test.b = '2'::text) (7 rows) postgres=# ``` 优化方法：索引条件上的常量尽可能使用和索引列相同类型的常量，避免发生隐式类型转化。 ## 4. 使用nestloop + indexscan 代替 hashjoin 此类语句的特征是两个表关联的时候，其中一个表上where条件过滤之后的结果集行数很小，同时，最终满足条件的结果集行数也很小。此时，使用nestloop+indexscan的效果往往要由于hashjoin。较优的执行计划如下： 可以看到，第5层的Index Cond: (t1.b = t2.b)已经把join条件下推到了基表扫描上。 ```postgres postgres=# explain verbose select t1.a,t1.b from t1,t2 where t1.b=t2.b and t2.a=4; id | operation | E-rows | E-distinct | E-memory | E-width | E-costs ----+--------------------------------------------------+--------+------------+----------+---------+--------- 1 | -> Streaming (type: GATHER) | 26 | | | 8 | 17.97 2 | -> Nested Loop (3,5) | 26 | | 1MB | 8 | 11.97 3 | -> Streaming(type: BROADCAST) | 2 | | 2MB | 4 | 2.78 4 | -> Seq Scan on public.t2 | 1 | | 1MB | 4 | 2.62 5 | -> Index Scan using t1_b_idx on public.t1 | 26 | | 1MB | 8 | 9.05 (5 rows) Predicate Information (identified by plan id) ----------------------------------------------- 4 --Seq Scan on public.t2 Filter: (t2.a = 4) 5 --Index Scan using t1_b_idx on public.t1 Index Cond: (t1.b = t2.b) (4 rows) Targetlist Information (identified by plan id) ------------------------------------------------ 1 --Streaming (type: GATHER) Output: t1.a, t1.b Node/s: All datanodes 2 --Nested Loop (3,5) Output: t1.a, t1.b 3 --Streaming(type: BROADCAST) Output: t2.b Spawn on: datanode2 Consumer Nodes: All datanodes 4 --Seq Scan on public.t2 Output: t2.b Distribute Key: t2.a 5 --Index Scan using t1_b_idx on public.t1 Output: t1.a, t1.b Distribute Key: t1.a (15 rows) ====== Query Summary ===== --------------------------------- System available mem: 9262694KB Query Max mem: 9471590KB Query estimated mem: 5144KB (3 rows) ``` 如果优化器没有选择这种执行计划，可以通过以下方式优化： set enable_index_nestloop = on; set enable_hashjoin = off; set enable_seqscan = off; ## 5. 使用hint指定索引时指定的索引方式不对 GaussDB(DWS)的plan hint当前支持指定的Scan方式有三种：tablescan、indexscan和indexonlyscan。 tablescan：全表扫描，比如行存表的Seq Scan，列存表的CStore Scan indexscan：先扫索引，再根据索引取表记录 indexonlyscan：覆盖索引扫描，所需的返回结果能被所扫描的索引全部覆盖。与index scan相比，index only scan所包含的字段集合，囊括了我们查询语句中的字段，这样，提取出相应的index ，就不必再根据索引取表记录了。 因此，对于需要indexonlyscan的场景，如果hint指定了indexscan，该hint是无法生效的： ```postgres postgres=# explain verbose select/*+ indexscan(test)*/ b from test where b = '1'; WARNING: unused hint: IndexScan(test) QUERY PLAN -------------------------------------------------------------------- Streaming (type: GATHER) (cost=3.12..16.88 rows=100 width=2) Output: b Node/s: All datanodes -> Seq Scan on public.test (cost=0.00..10.88 rows=100 width=2) Output: b Distribute Key: a Filter: (test.b = '1'::text) (7 rows) postgres=# postgres=# explain verbose select/*+ indexonlyscan(test)*/ b from test where b = '1'; QUERY PLAN -------------------------------------------------------------------------------------------- Streaming (type: GATHER) (cost=3.12..56.51 rows=100 width=2) Output: b Node/s: All datanodes -> Index Only Scan using test_b_idx on public.test (cost=0.00..50.51 rows=100 width=2) Output: b Distribute Key: a Index Cond: (test.b = '1'::text) (7 rows) ``` 优化方法：使用hint时正确指定indexscan和indexonlyscan。 ## 6. 全文检索gin索引 为了加速文本搜索，进行全文检索时可以创建GIN索引： ```postgres create index idxb on test using gin(to_tsvector('english',b)); ``` 创建索引时，必须使用to_tsvector的两参数版本，并且只有当查询时也使用了两参数版本，且参数值与索引中相同时，才会使用该索引： ```postgres postgres=# explain verbose select * from test where to_tsvector(b) @@ to_tsquery('cat') order by 1; QUERY PLAN -------------------------------------------------------------------------- Streaming (type: GATHER) (cost=22.23..27.87 rows=12 width=14) Output: a, b, c Merge Sort Key: test.a Node/s: All datanodes -> Sort (cost=21.86..21.87 rows=12 width=14) Output: a, b, c Sort Key: test.a -> Seq Scan on public.test (cost=0.00..21.78 rows=11 width=14) Output: a, b, c Distribute Key: a Filter: (to_tsvector(test.b) @@ '''cat'''::tsquery) (11 rows) postgres=# postgres=# explain verbose select * from test where to_tsvector('english',b) @@ to_tsquery('cat') order by 1; QUERY PLAN --------------------------------------------------------------------------------------------------- Streaming (type: GATHER) (cost=16.09..22.03 rows=2 width=14) Output: a, b, c Merge Sort Key: test.a Node/s: All datanodes -> Sort (cost=16.03..16.03 rows=2 width=14) Output: a, b, c Sort Key: test.a -> Bitmap Heap Scan on public.test (cost=12.00..16.02 rows=1 width=14) Output: a, b, c Distribute Key: a Recheck Cond: (to_tsvector('english'::regconfig, test.b) @@ '''cat'''::tsquery) -> Bitmap Index Scan on idxb (cost=0.00..12.00 rows=1 width=0) Index Cond: (to_tsvector('english'::regconfig, test.b) @@ '''cat'''::tsquery) (13 rows) ``` 优化方式：查询时也使用了两参数版本，且保证参数值与索引中相同。

本文分享自华为云社区《[华为云GaussDB(for Influx)揭秘第七期：最佳实践之数据建模](https://bbs.huaweicloud.com/blogs/349472?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=database&utm_content=content)》，作者： GaussDB 数据库。 华为云GaussDB(for Influx)时序数据库面向工业物联网海量时序数据场景提供数据安全、高性能、低存储成本、免运维等能力，受到越来越多企业的关注；同时，即开即用、使用简单、类SQL查询语句、无需设计schema、适合业务快速迭代等特点，也越来越得到开发者的认可。 但是随着业务规模不断增加，也会遇到诸如时间线暴涨、查询时延高、Tag和Field同名导致查询数据时有时无等问题，其根本原因是，在使用过程中没有良好的数据模型设计。本期将从GaussDB(for Influx)数据模型谈起，分享GaussDB(for Influx)数据建模的最佳方法，避免一些使用过程中的常见问题。 # 01 数据模型与关键概念  - **Database** 与MySQL中Database概念相同。 创建命令：CREATE DATABASE “mydb”。 用户权限、数据保留策略都以Database为粒度设置。比如赋予用户对“mydb”数据库只读权限：GRANT read ON mydb TO username。 - **Measurement** 与MySQL中Table概念类似。所不同的是，GaussDB(for Influx)属于Schemaless，Measurement不需要提前创建，也不需要设计表中的字段和类型。写入数据时自动创建Measurement，字段可以任意新增和减少，但要求相同字段的数据类型必须一致。  - **Retention Policy（RP）** 数据保留策略，是关系型数据库中不存在的概念，专为时序场景设计，意为指定数据在数据库中的最长保存时间，过期数据会自动被清理。 - **Tag** 数据源标识，只支持string类型 - **Field** 采集指标，支持string，float，int，bool类型 - **Line Protocol（数据模型）**  如图所示，写数据到GaussDB(for Influx)，单条数据由measurement、Tag_key、Tag_value、Field_key、Field_value、timestamp 6部分组成。可以1个或多个，可以1个或多个，每条数据必须要携带时间戳。 - **Point（点）** Point通常包含measurement+Tags+Field+timestamp 4个部分。例如，如下数据包含2个Point。 Point1： Point2： 即，一条数据包含多少Field Key，则可以简单认为存在多少Point。在GaussDB(for Influx)中，可以一条数据包含一个Point，也可以包含多个Point。 - **Series（时间线）** 在GaussDB(for Influx)里，我们将一个指标+一组Tag组合称为一条时间线。在一条时间线下面，连续时间点的采样数据则为时序数据。比如有数据： monitorInfo，area=”葡萄花”，device=”钻机A”，pressure=1.8，1650443961100400200 monitorInfo，area=”葡萄花”，device=”钻机B”，pressure=1.6，1650443961100400200 monitorInfo，area=”榆树林”，device=”钻机B”，pressure=1.7，1650443961100400200 monitorInfo，area=”榆树林”，device=”钻机A”，pressure=1.5，1650443961100400200 表示4条时间线，分别是： 葡萄花油田的钻机A上的压力传感器(pressure) 葡萄花油田的钻机B上的压力传感器(pressure) 榆树林油田的钻机B上的压力传感器(pressure) 榆树林油田的钻机A上的压力传感器(pressure) # 02 数据建模之最佳实践 通常，数据建模是为了让查询更简单、更高效。对于大多数使用情形，我们建议使用以下设计准则： ## 1、合理设计Tag 和Field - Tag只支持字符串类型，数值和布尔类型数据应该被设计为Field； - 将常用查询条件和分组条件设计为Tag； 因为Tag会创建索引，而Field则没有索引。比如在业务中，经常会查询某一台机器的平均CPU利用率： ```mysql SELECT mean(cpu) FROM monitor WHERE host=“192.168.1.1” AND time > now() – 1h ``` 或者查询风电场每台风力发电机每小时的平均发电量： ```mysql SELECT mean(elect) FROM monitor WHERE farm_id=“737f738a-bd63” AND time > now() – 24h GROUP BY time(1h)，device_id ``` 则应该将上述查询语句中的 host、farm_id、device_id 设置为Tag，前提是字符串类型才能被设为Tag。 - time属于内置关键字，不能作为Tag_key和Field_key； - 使用InfluxQL函数（Max、Min、Count等）的字段，作为Field存储。 ## 2、 遵守Tag_Key 和Field_Key的命名约定 - 不使用保留关键字作为Tag和Field的key（名称）； - Tag和Field不使用相同名称，否则会出现不可预料的问题； - Tag和Field名称尽量简短清晰，可以节约Index内存空间，同时会让查询更加高效； - 避免一个Tag中包含多层意思，比如machine = “192.168.2.1-Ubuntu”，包含ip地址和操作系统名称，建议拆分为两个Tag：host和os； - 建议将变化小的数据设置为Tag，比如进程名称可以设为Tag，而进程号则建议设置为Field。 ## 3、避免超过节点规格所能承受的时间线数量 GaussDB(for Influx)规格与时间线数量对应关系如下：  时间线过度超过限制，会引起性能急剧下降，可能会影响业务运行，需要考虑对节点扩容。 ## 4、避免一张表中存在过多Tag或者 Field 建议一张表存放同一类业务数据，比如物流车辆监测数据。过多业务数据放置到同一张表，会造成Tag和Field数量激增，直接影响查询效率。Field太多时，每个Field的计算都会单独计算，当执行模糊查询时可能会导致查询超时。 ## 5、避免同一个Retention policy存储多用户数据 不同业务数据的过期时间不尽相同，应根据业务具体需求分别存储在不同的RP中，否则过期数据不能及时删除，依然占据存储空间，增加了数据存储成本，影响了查询效率。 ## 6、避免同一个Database存储多用户数据 由于当前GaussDB(for Influx)的权限控制粒度是DB级别，同一个Database保存多用户数据，容易导致数据被其他用户访问和修改。建议不同用户使用单独Database，并且只对单一用户授予访问权限。 # 03 总结 在制造、能源、农业、电力等工业物联网行业中，大部分数字化信息系统是构建在MySQL等关系型数据库基础上。但随着企业业务和规模的进一步扩大，数据量迅速增长，MySQL等关系型数据库面临并发数、存储成本、查询性能、扩展性、维护等诸多问题，正逐渐被时序数据库所替代。 GaussDB(for Influx)摒弃关系型数据库范式化繁复的设计规则，支持Schemaless设计，业务能按照简单、高效的方式建模。面对业务变化快、接入设备多样化严重的工业物联网场景，GaussDB(for Influx)数据建模表现更加灵活，无需更改业务即可兼容不同设备，更适用于工业物联网场景。

本文分享自华为云社区《[GaussDB(DWS) OLAP函数浅析](https://bbs.huaweicloud.com/blogs/349413?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者： DWS_Jack_2。 在一些报表场景中，经常会对数据做分组统计（group by），例如对一级部门下辖的二级部门员工数进行统计 create table emp( id int, --工号 name text, --员工名 dep_1 text, --一级部门 dep_2 text --二级部门 ); gaussdb=# select count(*), dep_2 from emp group by dep_2; count | dep_2 -------+------- 200 | SRE 100 | EI (2 rows) 常见的统计报表业务中，通常需要进一步计算一级部门的“合计”人数，也就是二级部门各分组的累加，就可以借助于rollup，如下所示，比前面的分组计算结果多了一行合计的数据 gaussdb=# select count(*), dep_2 from emp group by rollup(dep_2); count | dep_2 -------+------- 200 | SRE 100 | EI 300 | (3 rows) 如上是一种group by扩展的高级分组函数使用场景，这一类分组函数统称为OLAP函数，在GaussDB(DWS)中支持 ROLLUP，CUBE，GROUPING SETS，下面对这几种OLAP函数的原理和应用场景做一下分析。 首先我们来创建一张表，customer，用户信息表，其中包含了用户id，用户名，年龄，国家，用户级别，性别，余额等信息 create table customer ( c_id char(16) not null, c_name char(20) , c_age integer , c_country varchar(20) , c_class char(10), c_sex text, c_balance numeric ); insert into customer values(1, 'tom', '20', 'China', '1', 'male', 300); insert into customer values(2, 'jack', '30', 'USA', '1', 'male', 100); insert into customer values(3, 'rose', '40', 'UK', '1', 'female', 200); insert into customer values(4, 'Frank', '60', 'GER', '1', 'male', 100); insert into customer values(5, 'Leon', '20', 'China', '2', 'male', 200); insert into customer values(6, 'Lucy', '20', 'China', '1', 'female', 500); # ROLLUP 本文开头的示例已经解释了，ROLLUP是在分组计算基础上增加了合计，从字面意思理解，就是从最小聚合级开始，聚合单位逐渐扩大，例如如下语句 select c_country, c_class, sum(c_balance) from customer group by rollup(c_country, c_class) order by 1,2,3; c_country | c_class | sum -----------+------------+------ China | 1 | 800 China | 2 | 200 China | | 1000 GER | 1 | 100 GER | | 100 UK | 1 | 200 UK | | 200 USA | 1 | 100 USA | | 100 | | 1400 (10 rows) 该语句功能等价于如下 select c_country, c_class, sum(c_balance) from customer group by c_country, c_class union all select c_country, null, sum(c_balance) from customer group by c_country union all select null, null, sum(c_balance) from customer order by 1,2,3; c_country | c_class | sum -----------+------------+------ China | 1 | 800 China | 2 | 200 China | | 1000 GER | 1 | 100 GER | | 100 UK | 1 | 200 UK | | 200 USA | 1 | 100 USA | | 100 | | 1400 (10 rows) 尝试理解一下 GROUP BY ROLLUP(A,B)： 首先对(A,B)进行GROUP BY，然后对(A)进行GROUP BY，最后对全表进行GROUP BY操作 # CUBE CUBE从字面意思理解，就是各个维度的意思，也就是说全部组合，即聚合键中所有字段的组合的分组统计结果，例如如下语句 select c_country, c_class, sum(c_balance) from customer group by cube(c_country, c_class) order by 1,2,3; c_country | c_class | sum -----------+------------+------ China | 1 | 800 China | 2 | 200 China | | 1000 GER | 1 | 100 GER | | 100 UK | 1 | 200 UK | | 200 USA | 1 | 100 USA | | 100 | 1 | 1200 | 2 | 200 | | 1400 (12 rows) 该语句功能等价于如下 select c_country, c_class, sum(c_balance) from customer group by c_country, c_class union all select c_country, null, sum(c_balance) from customer group by c_country union all select null, null, sum(c_balance) from customer union all select NULL, c_class, sum(c_balance) from customer group by c_class order by 1,2,3; c_country | c_class | sum -----------+------------+------ China | 1 | 800 China | 2 | 200 China | | 1000 GER | 1 | 100 GER | | 100 UK | 1 | 200 UK | | 200 USA | 1 | 100 USA | | 100 | 1 | 1200 | 2 | 200 | | 1400 (12 rows) 理解一下 GROUP BY CUBE(A,B)： 首先对(A,B)进行GROUP BY，然后依次对(A)、(B)进行GROUP BY，最后对全表进行GROUP BY操作。 GROUPING SETS GROUPING SETS区别于ROLLUP和CUBE，并没有总体的合计功能，相当于从ROLLUP和CUBE的结果中提取出部分记录，例如如下语句 select c_country, c_class, sum(c_balance) from customer group by grouping sets(c_country, c_class) order by 1,2,3; c_country | c_class | sum -----------+------------+------ China | | 1000 GER | | 100 UK | | 200 USA | | 100 | 1 | 1200 | 2 | 200 (6 rows) 该语句功能等价于如下 select c_country, null, sum(c_balance) from customer group by c_country union all select null, c_class, sum(c_balance) from customer group by c_class order by 1,2,3; c_country | ?column? | sum -----------+------------+------ China | | 1000 GER | | 100 UK | | 200 USA | | 100 | 1 | 1200 | 2 | 200 (6 rows) 理解一下 GROUP BY GROUPING SETS(A,B)： 分别对(B)、(A)进行GROUP BY计算 目前在GaussDB(DWS)中，OLAP函数的实现，会有排序(sort)操作，相比等价的union all操作，效率并不会有提升，后续会通过mixagg的支持来提升OLAP函数的执行效率，有兴趣的同学，可以explain打印一下计划，来看一下OLAP函数的执行流程。

【问题现象】执行计划中Stream和Gather算子慢，等待视图中有wait quota/stream get conn等等待事件【版本信息】：HCS 8.0.1【问题影响】客户查询出现性能劣化，语句执行时间从3s劣化到10min+【排查过程】1. 查看网络重传情况，网络重传率高    cd $GAUSSHOME/bin/dfx_tool    sh gsar.sh 网卡名    输出结果中，最后一列表示网络重传率，一般不超过0.02%2. 查看messages日志，日志中有大量Bringing up interface/NetworkManager state等日志，如果有此类内容，说明网络服务一直在被重启，需要修改netCardMonitor.sh的脚本【问题原因】    netCardMonitor.sh脚本因为逻辑判断错误每分钟都重启 service network restart，影响网络建联，导致查询stream和gather算子慢。    netCardMonitro.sh脚本路径：/rds/mgntAgent/v8.1.1.2/os/linux/    该脚本日志路径：/var/log/netcardMonitor.log【解决方法】    在沙箱外操作，对所有节点修改：    cd /rds/mgntAgent/v8.1.1.2/os/linux/    vi netCardMonitor.sh    注释66-77行对应的内容；    同时，需要清理残留的dhclient进程：ps -ef| grep dhclient| grep -v grep |awk '{print $2}'|xargs kill -9【参考资料】    纯软场景下stream和gather慢的案例：https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=136091

Oracle操作如下：GaussDB A 8.1.0 执行报错，tables不存在：

问题描述: 对接周边系统：安装Service OM插件 子任务工步报错错误信息:HCS-Deploy859500,执行任务失败,错误信息:Failed to get token from om,url:goku/rest/v1.5/tokens问题版本：HCS 8.1.0问题原因：操作问题，LLD中serviceOM密码填写错误恢复方案：配置表serviceOM保留默认密码，重新导入LLD，并重试

本文分享自华为云社区《[​​​​​​​GaussDB(DWS) 时间域函数​​​​​​​](https://bbs.huaweicloud.com/blogs/317197?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者： 积少成多。 # 1. 什么是时间域函数，有哪些？ 时间域函数是指数据库内获时间戳每部分值的函数。现有的时间域函数包括：  1) quarter函数：获取季度  2) hour函数：获取小时数  3) minute函数：获取分钟数  4) second函数：获取秒数  5) microsecond函数：获取微秒数。 # 2. 时间域函数参数的解析 时间域函数的入参类型有四种，包括：   1) date类型   2) timestamp/timestamptz类型   3) time/timetz类型   4) text类型。text类型的输入会根据输入格式转换为对应的date、timestamp/timestamptz或time类型。                   时间域函数入参支持类型表 参数解析支持时区设置，当输入参数含时区时，结果会转换为当前时区。以下用例中，数据库的默认时区为+08：00时区。  # 3. 结果展示  # 4.总结   时间域函数是为获取时间戳各部分值而增加的函数。支持对text类型入参的的解析，使text类型入参进行隐式转换，解析成为对应时间戳类型获取目标值，更贴近实际场景。 **想了解GuassDB(DWS)更多信息，欢迎微信搜索“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技，后台还可获取众多学习资料哦~**

【功能模块】在DWS创建OBS外表后，将数据导入外表报错Failed to open file region_map【操作步骤&问题现象】1、再dws上创建存储为OBS的外表2、将DWS数据insert到外表【截图信息】建表语句：【日志信息】（可选，上传日志内容或者附件）

【功能模块】产品文档中的“配置和检查安装环境”模块【操作步骤&问题现象】1、在配置安装环境时，编辑preinstall配置文件结束后使用./setuptool.sh preinstall -n执行配置文件时出现报错该怎样解决？【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】GaussDB DWS在环境搭建时需要配置规划工具，官网上给出了规划工具，产品文档中要求至少一个系统盘一个数据盘，但是我只买了一块磁盘，而使用规划工具时至少需要三块磁盘才能布置成功。【操作步骤&问题现象】1、只有一块磁盘能搭建完成吗？2、如果不行，那我应该怎样把一块磁盘分区，分为三块呢？【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】用spark 读hive 写gaussdb代码如下：取hive一条数据测试【操作步骤&问题现象】提交到yarn上 client模式  但是出现如下问题：、请问如何解决？是配置问题 ，还是其它问题？【截图信息】【日志信息】（可选，上传日志内容或者附件）

请问有没有适用于Euler-aarch64系统的GaussDB性能测试工具？官方的验收测试和对应的工具使用时，在aarch64系统中会出现【cannot execute binary file: Exec format error】的报错。请大家推荐一下吧。

【功能模块】【操作步骤&问题现象】我用spark读Hive数据 然后写入gaussdb时  出现下述问题为了方便测试，取了hive的一条数据，然后写gaussdb  ；submit 提交到yarn集群跑的，client模式。请问是写错了，还是哪里配置的不对？谢谢【截图信息】【日志信息】（可选，上传日志内容或者附件）

【操作步骤&问题现象】GaussDB A 800版本，使用连接池疑问必须使用“SET SESSION AUTHORIZATION DEFAULT;RESET ALL;”将连接的状态清空。如果使用了临时表，那么在将连接归还连接池之前，必须将临时表删除。这两块如何通过代码实现？在使用连接池执行任务时如何能取消集群内正在执行的sql？

【功能模块】DMAX-->数据中心,新建数据源连接DWS数据库【截图信息】【日志信息】（可选，上传日志内容或者附件）