项目交付中可能会遇到同时包含核心交易（OLTP）和报表分析（OLAP）的混合业务场景，其中报表分析类业务复杂度高，消耗大量系统资源，但实时性要求较低，而核心交易类业务并发较大，多为简单事务处理，对实时性要求高。当系统处于业务高峰时，报表分析类业务并发操作会加剧系统负载，且长时间占用资源无法释放，最终可能导致整体性能裂化，实时性要求较高的核心交易类业务因资源争抢而无法得到响应，从而影响客户整体体验。资源管控的目的是基于业务场景和可用资源，进行合理的资源与并发度管控，以保障数据库可以在高负载场景下正常运行，不会因为资源争抢和耗尽出现系统卡死，提升系统整体吞吐量。业务场景主要分为核心交易（OLTP）和报表分析（OLAP）两大类，其中报表服务的优先级相对较低，在合理的情况下优先保障业务系统的正常运行。业务系统中运行的SQL分为简单SQL和复杂SQL，大量复杂SQL的并发执行会导致数据库服务器资源争抢，简单SQL的大量并发对服务器不构成持续压力，短时间内可执行完成，不会造成业务堆积。其中报表服务中运行的SQL以复杂SQL居多，整体业务逻辑相对复杂，在数据库层面需要分别对核心交易和报表服务进行合理的资源管控，以保障业务系统正常运行。

通常情况下，会生成基表扫描的查询计划，即对于customer表的每一条，需要检查c_customer_sk列是否会和IN list中的某个值匹配，匹配即返回该条元组。当IN list中的条件比较多时，匹配近似于NestLoop的操作。针对这种场景，GaussDB(DWS)实现了In list to Join的查询优化规则，根据代价估算，针对In list中的值较多的场景，生成Hash Join的计划，极大提升性能，如下图所示：但代价估算存在估算不准的情况，对于列存表有min/max过滤，有时转成Join并不一定性能最好，因此我们增加了GUC参数：qrw_inlist2join_optmode，用户可以手动设置该参数的值进行调优，其值说明如下：a)   cost_base，即根据代价估算，默认值。b)   rule_base，强制使用转换成Join的优化规则。c)   不小于2的整数，表示当In list中的常量个数不小于N时，使用转换成Join的优化规则。在GaussDB(DWS)场景中，经常会遇到一类SQL，其中存在大量的冗余操作，导致执行时进行了大量无效计算。这类语句的场景很多，需要根据performance数据详细分析，以下举几个例子简单看一下。（1）语句中存在大量冗余case when语句的场景例如如下语句，语句中有大量case when语句，大多数条件都是一样的，只是default值存在不同，但执行时，每个分支的case when均需要执行，导致时间成倍增加。这种情况下需要对语句进行深入分析，根据语义进行等价改写。通常我们可以把case when加到过滤条件，分成多个子查询分别求值，或提取公共部分进行改写。经过优化后，消除了case when，性能得到了提升，修改后的语句如下所示。我们发现对所有的数据进行了排序，然后返回了前10条数据，数据量较大时，所有数据量全排将大量耗费时间。这种情况下，我们可以在子查询中加入limit语句，这样排序变为top N排序，减少了排序的时间，修改后的语句为：select a from (select a, row_number() over (order by a desc) rid from t1 limit <end>-<start>+1 offset <start>-1) where rid between 1 and 10;在GaussDB(DWS)场景中，通常为分析类应用，最终均需要进行聚集操作。通常聚集都是在语句最后进行，起到去重统计的效果。但是，如果去重前的重复值较多，但会显著影响关联的性能，如SQL语句：select t1.c1, count(*) from t1 join t2 on t1.c1=t2.c1 group by t1.c1;我们称这个改写规则为Eager Agg，相反，如果改写后的语句，在子查询中的Agg去重效果不明显，但耗时较长，则可以做反向改写，去除冗余的Agg操作，我们称之为Lazy Agg。转载：https://mp.weixin.qq.com/s/Jy27HVRIIuEXddrifXFlFw

相关子查询，即子查询中需要依赖父查询的列值进行迭代计算的场景。例如如下语句：select (select ss_item_sk from store_sales where ss_item_sk<i_item_sk limit 1) from item;计划如下：在分布式框架下，为了保证每一行父查询元组均能够在子查询中迭代计算出结果，需要所有DN均维护一份子查询表的全局数据，在上面的计划中，子查询中的store_sales表进行了广播和物化，将数据存在所有DN上，见8层算子。第3层算子每一行数据均需要通过迭代子查询计算（第4层及之下的SubPlan 1）获得是否匹配的信息。这个计划执行非常慢且耗费资源，原因是：a)   在DN节点非常多的分布式环境下，将数据广播到所有DN上进行物化，将导致网络资源和IO资源耗费巨大，同时大数据量的广播耗时也很长。b)   对于父查询的每一行元组，均需要迭代计算子查询的值，类似于NestLoop的执行方式，效率极低。以上两个问题带来的语句性能问题在各个客户现场均被识别，因此需要进行通用子链接提升转成join的查询重写来解决该问题。在之前的版本中，我们已经支持了如下场景的子链接提升，即将子链接转化为join获得性能提升，这些子链接均出现在where条件里，包括：a)    IN/NOT IN的非相关子查询。b)   EXISTS/NOT EXISTS的等值相关子查询。c)    包含Agg表达式的等值相关子查询。d)   以上场景子查询的OR场景。当然，目前我们还不支持目标列上出现相关子查询的场景，以及相关子查询中出现不等值比较的场景，需要首先识别出坏味道，进行语义等价的整改。转载：https://mp.weixin.qq.com/s/Jy27HVRIIuEXddrifXFlFw

GaussDB(DWS)分布式数据库的优势，就是利用多DN的资源进行并行计算，提高吞吐量。但有些SQL在这些方面不够注意，导致执行过程中由于全局性操作仅能在一个DN或CN上执行，造成了性能瓶颈。不能下推即属于这一类型问题。除了不能下推，本章节主要讨论在DN上进行全局操作导致的问题。客户场景遇到的主要问题，是需要对全量大数据量进行排序的问题，比如：windowagg函数没有partition by，但包含order by的问题。例如如下语句：select * from (select ss_sold_date_sk, sum(ss_sales_price) over  (order by ss_sold_date_sk rows 2 preceding)  sum_2, sum(ss_sales_price) over (order by ss_sold_date_sk rows 5 preceding) sum_5 from store_sales), date_dim where ss_sold_date_sk=d_date_sk and d_year=2000 and d_moy=5 order by 1;计划中第4层将所有DN的数据广播到一个DN上进行全局排序，并计算sum窗口函数的值，导致性能瓶颈。对于类似情况，在语义允许的情况下，尽量给窗口函数增加partition by的字段，这样分组计算时，GaussDB(DWS)可以将计算分配到不同的DN上进行，提高执行效率。NestLoop是最简单的表关联手段，当然也是最低效的，每条元组之间都要进行匹配，数据量大的时候经常执行不出来。所以在GaussDB(DWS)中，我们经常使用HashJoin进行表的关联。但有些SQL语句从语义上决定，只能使用NestLoop的方式执行，导致性能问题。总结起来，有以下几方面：在GaussDB(DWS)中，我们推荐使用等值关联，这样可以使用HashJoin进行执行加速。但对于非等值关联条件，只能使用NestLoop的方式进行连接，同时需要将其中一个表进行Broadcast广播到所有DN进行。如果两个表都比较大，将导致性能瓶颈。例如如下：select * from t1 join t2 on t1.a<t2.a;类似的场景还有：<1> select * from t1 join t2 on 1=1;这个语句无关联条件，我们称为笛卡尔积关联，返回结果行数为t1和t2行数的乘积。<2> select * from t1 join t2 on t1.a=t2.a and t1.a=5;这个语句虽然有等值关联条件，但关联条件还有个过滤条件t1.a=5，所以实际上t1.a=t2.a=5，是在a=5过滤基础上的笛卡尔积。这类语句都会导致性能瓶颈。转载：https://mp.weixin.qq.com/s/Jy27HVRIIuEXddrifXFlFw

数据库在进行不同列的比较、计算运算时，如果类型不同，需要进行类型转换。通常情况下，由优化先低的类型往优先级高的类型转换，字符串的优先级较数字较低，同时数字类型，精度低的会向精度高的转换。在应用中，经常遇到的是，字符串和数字进行比较，导致字符串需要转成数字进行比较操作。由于数据库的基本调优都是基于基表列的，数据转换后就会带来以下性能问题：（1）无法使用索引。由于索引是基于列的排序构造的，字符串转换成数字后的排序性与字符串不一致（’2’与’12’，字符串’2’大，数字12大），故无法使用索引，对于返回数据量少的场景，使用全表扫描带来性能问题。（2）无法进行分区剪枝。GaussDB(DWS)支持range分区，即根据分区键值的范围创建不同的分区。当需要进行分区键上的范围操作时，进行分区剪枝。而字符串转换成数字后，道理与（1）类似，打破排序性，导致分区剪枝失效。（3）需要进行网络重分布操作。在进行表的关联，聚集操作时，如果涉及表分布键的操作，可以在本地并行进行。但如果涉及到类型转换，则hash值发生变化，需要进行网络重分布，增加了网络开销。（4）估算不够准确，可能造成计划的性能问题。我们收集的统计信息都是基于基表列的，如果进行类型转换，则缺少转换后的统计信息，同样可能造成计划不准。因此，在表设计之初就要把数据类型定义好，数字类型尽量使用整型或numeric（浮点型），尽量少使用字符串数据类型，除了与数字比较产生上述开销外，变长的字符串在处理时还产生了额外的空间申请释放，内存拷贝的开销，都是无形中性能的损耗。在share-nothing架构的分布式场景下，数据使用哈希分布在不同DN上，并且通过数据重分布使得中间结果均匀分布在各个DN上进行并行计算，进行执行查询的加速。所以在执行过程中，一直保持数据能够均匀分布在DN上，是保证性能的关键。通常情况下，我们需要进行表的关联(Join)和聚集(Agg)操作，这就需要关联和聚集列能够支持重分布，从而进行灵活的重分布操作。在GaussDB(DWS)中，不支持重分布的类型主要有real和double类型，因此使用这两种类型进行操作时，将导致无法生成重分布的计划，在实际使用时要尽量避免。首先，在进行表定义时，要尽量避免使用这两种类型，使用numeric类型进行替代。同时，还要避免使用返回值为这两种类型的函数，进行关联和聚集运算，例如：ceil, floor, pow, sqrt, 以及一些分析类聚集函数如stddev_samp等。如果必须使用此类函数进行相关运算，需要在计算完对这些类型进行类型转换，转换成numeric类型。转载：https://mp.weixin.qq.com/s/Jy27HVRIIuEXddrifXFlFw

springboot使用mybatis-plus连接openGauss-5.0.1，使用between查询时报错，请各位大神帮忙排查！！！报错信息如下： jdbc.sqltiming                           : 6. PreparedStatement.execute() FAILED! SELECT DATE_FORMAT(alarm_time, '%Y-%m-%d 00:00:00') AS time, alarm_level as alarmLevel, IFNULL(COUNT(*),0)  AS count FROM monitor_alarm WHERE (alarm_level IN ('1','2','3','4','5') AND alarm_time BETWEEN  '2024-04-10 17:06:45' AND '2024-04-17 17:06:45') GROUP BY DATE_FORMAT(alarm_time, '%Y-%m-%d  00:00:00'), alarm_level   {FAILED after 58 msec}  org.postgresql.util.PSQLException: [************:5432] ERROR: could not determine data type of parameter $6     at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2922)     at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2643)     at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:375)     at org.postgresql.jdbc.PgStatement.runQueryExecutor(PgStatement.java:561)     at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:538)     at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:396)     at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:166)     at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:155)     at net.sf.log4jdbc.PreparedStatementSpy.execute(PreparedStatementSpy.java:417)     at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:497)     at org.apache.ibatis.executor.statement.PreparedStatementHandler.query(PreparedStatementHandler.java:64)     at org.apache.ibatis.executor.statement.RoutingStatementHandler.query(RoutingStatementHandler.java:79)     at sun.reflect.GeneratedMethodAccessor142.invoke(Unknown Source)     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)     at java.lang.reflect.Method.invoke(Method.java:498)     at org.apache.ibatis.plugin.Plugin.invoke(Plugin.java:63)     at com.sun.proxy.$Proxy96.query(Unknown Source)     at com.baomidou.mybatisplus.core.executor.MybatisSimpleExecutor.doQuery(MybatisSimpleExecutor.java:69)     at org.apache.ibatis.executor.BaseExecutor.queryFromDatabase(BaseExecutor.java:325)     at org.apache.ibatis.executor.BaseExecutor.query(BaseExecutor.java:156)     at com.baomidou.mybatisplus.core.executor.MybatisCachingExecutor.query(MybatisCachingExecutor.java:165)     at com.baomidou.mybatisplus.extension.plugins.MybatisPlusInterceptor.intercept(MybatisPlusInterceptor.java:81)     at org.apache.ibatis.plugin.Plugin.invoke(Plugin.java:61)     at com.sun.proxy.$Proxy95.query(Unknown Source)     at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:147)     at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:140)     at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source)     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)     at java.lang.reflect.Method.invoke(Method.java:498)     at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:426)     at com.sun.proxy.$Proxy92.selectList(Unknown Source)     at org.mybatis.spring.SqlSessionTemplate.selectList(SqlSessionTemplate.java:223)     at com.baomidou.mybatisplus.core.override.MybatisMapperMethod.executeForMany(MybatisMapperMethod.java:173)     at com.baomidou.mybatisplus.core.override.MybatisMapperMethod.execute(MybatisMapperMethod.java:78)     at com.baomidou.mybatisplus.core.override.MybatisMapperProxy$PlainMethodInvoker.invoke(MybatisMapperProxy.java:148)     at com.baomidou.mybatisplus.core.override.MybatisMapperProxy.invoke(MybatisMapperProxy.java:89)     at com.sun.proxy.$Proxy166.selectMaps(Unknown Source)     at cn.hite.monitor.alarm.manager.RemoteClientAlarmManager.alarmList(RemoteClientAlarmManager.java:65)     at cn.hite.monitor.alarm.controller.AlarmController.alarmList(AlarmController.java:179)     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)     at java.lang.reflect.Method.invoke(Method.java:498)     at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190)     at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138)     at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:105)     at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:878)     at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:792)     at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)     at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1040)     at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)     at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)     at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)     at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)     at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)     at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)     at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)     at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)     at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)     at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)     at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)     at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)     at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)     at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)     at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:450)     at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)     at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)     at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)     at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:387)     at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)     at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)     at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)     at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542)     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)     at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:374)     at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)     at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)     at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1707)     at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)     at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)     at java.lang.Thread.run(Thread.java:750) 

我们现在有一个自动打开集群控制台的程序（https://xxx.xxx.xxx.xxx:28443/web）但是每天次打开都出现这个证书无效的界面，如下图所示，目前没有办法识别这个界面，所以有没有什么办法 不显示这个界面，打开网址就直到输入用户名和密码的界面，比如，向浏览器中导入根书，但我又没有证书。

上周末我们就会封板D-SMART高斯生态版了，这个版本是基于D-SMART V2.6基础版开发的，不过与惯例不同的是，我们这回会先发D-SMART高斯生态版，两周后再发标准版V2.6。在V2.6版本中有两个十分重要的新增功能，其中第一个是图形化的集群拓扑，这个功能是专门为Gaussdb开发的，为了支持其他D-SMART能纳管的数据库，我们还需要做一些改造工作。随着D-SMART对国产数据库的支持越来越多，集群拓扑的重要性也越来越高，无论是分布式数据库还是集中式数据库，在用户的生产环境中大多数都会以集群方式部署。老的字符界面的集群拓扑对专家友好，但是对普通运维人员来说看起来不够直观。 在集群拓扑上，你还可以点击某个CN/DN节点，进行下钻分析。对于Gaussdb来说，集群和CN/DN是独立的运维对象，你既可以对集群的健康状态进行分析，也可以对某个节点进行单独分析。节点的数据库类型是不同的，类似一个独立的集中式数据库。第二个比较重大的改进是支持了一种新的泛化分析工具-基于运维原理的指标集分析工具，这个工具就是昨天我说的写三行代码的工具。对于智能化运维工具来说，强大的智能的背后都是巨大的人工。要想让系统有更强的自动化分析能力，需要大量的能够针对某个具体的问题进行分析诊断与定位的工具。基于D-SMART的基础能力，如果我们的某个问题的分析定位可以通过某几个指标来完成，那么我们只需要写三行代码就可以完成一个分析工具的开发工作。          上面几行代码的实际执行效果如上图，对于某些能够梳理出来的问题分析场景，其分析结果对于稍微有经验的运维人员来说还是比较容易理解的。这个工具比泛路由工具更为精准，与泛路由工具结合，可以获得更好的效果。 上面是针对同一个故障告警，利用泛路由工具的分析结论。在需要更泛化的分析辅助的时候，使用泛路由工具更加有效，而对于已经比较明确的问题的定位，新的工具效果更佳。目前这个功能仅对商用版提供，还没有开放到社区版中。高斯生态版支持的运维对象类型为OS/GaussDB和高斯生态产品。高斯生态产品包含了GaussDB的CN/DN节点以及openGauss与相关生态的商用产品。目前我们已经适配了openGauss 2.x-5.x，实际上新的6.0也是没问题的。除此之外，我们已经完成了与南大通用GBASE 8C、海量、恩墨MogDB等数据库的适配工作。其他高斯生态的数据库厂商如果需要适配，可以和社区联系，我们会尽快纳入。对于Gaussdb我们将支持轻量化部署的线下版，也将支持云环境的版本（公有云和私有云），我们随后将会和华为生态部门调试云上的采集接口。高斯生态版的默认首页也采用了全新的贴片界面，对于集群数据库而言，在贴片首页上我们可以只显示集群对象，而CN/DN节点被隐藏在后面，可以通过集群拓扑界面进入。不过这些对象的告警还是会被推送到首页和告警短信等位置。从上面的告警我们可以看到在首页中没有看到的DN/CN节点的告警信息。          在功能上，高斯生态版延续了几乎所有的标准版的功能，同时也提供HOLA工具，让用户可以下载监控数据，交给远程专家导入到一个D-SMART中进行离线分析，或者进行远程巡检等工作。本周我们将完成高斯生态版的封板工作，届时会在DBAIOPS社区发布下载的链接，对于正在使用Gaussdb或者相关生态数据库产品的朋友，欢迎下载并申请使用。我们也将会在一个月内为申请的朋友免费赠送终身使用许可证。一个数据库运维工具必须在用户的真实环境中使用才能逐步完善，也希望朋友们帮我们完善这个产品。    

DWS 8.1.1.5版本，CStoreCUCacheSweepLock 用于列存CU Cache循环淘汰。这个的实现原理是什么？只有vacuum full 或vacuum full analyze的时候会触发吗？

SQL于关系型数据库而言，重要性不言而喻。就像一个乐团的指挥，指导着作品的正确演绎和节奏的和谐统一。华为云GaussDB作为新一代关系型分布式数据库，具备卓越的技术性能和行业竞争力。很多人对GaussDB的关键技术很好奇，纷纷在论坛上提问，《GaussDB SQL查询语句执行过程解析》技术文为您答疑解惑，从GaussDB SQL引擎入手，深度学习GaussDB SQL 查询语句的执行过程，包括GaussDB SQL引擎原理和关键技术点。如果您在了解过程中，有任何疑问或者感兴趣的关键技术点，可在本帖下方进行留言提问，专家会一对一进行答疑哦！参与评论并提出优质问题的用户，可获得相关礼品的激励！本期活动邀请了华为云GaussDB布道师许老师坐堂，帮助大家答疑GaussDB SQL引擎方面的数据库问题。【本期云咖】【问题参考】（不限于）GaussDB SQL语句到底是如何执行的？GaussDB SQL引擎原理是什么？GaussDB SQL有哪些关键技术点？……对于GaussDB SQL引擎方面的相关问题，你有哪些疑问呢？【活动时间】2024年4月23日-5月12日【参与方式】直接在此活动帖下方回帖提问即可。【获奖规则】参与云咖问答的提问我们会整理在问答专题中，你的提问将会帮助更多的开发者~欢迎大家踊跃提问，积极互动~【活动规则】1、开发者用户发布的提问，必须与本期产品相关，其他产品求助帖不参与此次活动，将视为无效内容，否则取消该用户获奖资格。（其他产品求助可发帖到相应的版块进行提问）；2、本次活动不限用户的总提问数及连续提问数，但需保证提问质量，如华为云社区小编认定参与用户有恶意灌水嫌疑，则取消该用户获奖资格；3、本次活动将根据实际参与情况发放奖励，包括但不限于用户百分之百中奖或奖项轮空的情况；以上奖品均为实物奖品，具体发放视出库情况而定；4、每期活动预计于结束后10天内完成奖项公示，并于结束后30个工作日内完成邮寄。【温馨提示】1、请务必使用个人实名账号参与活动（IAM、企业账号等账号参与无效）。如一个实名认证对应多个账号，只有一个账号可领取奖励，若同一账号填写多个不同收件人或不同账号填写同一收件人，均不予发放奖励。2、所有获得奖品的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。

背景信息在准备POC测试，在公司环境在通过云数据库GaussDB管理平台在安装实例时遇到报错信息。cpu Intel(R) Xeon(R) Gold 6348H CPU   内存128G。 磁盘单个磁盘500G。环境信息：操作系统版本：Kylin Linux Advanced Serverrelease V10 (SP1) /(Tercel)-x86_64-Build20/20210518CPU信息内存情况任务失败截图。任务详情页详细的报错信息。请大佬协助看一下啥原因。我想知道的是，华为云数据库GaussDB轻量化部署模式，不能和操作系统盘部署在一起吗？还是说必须部署单独的磁盘。这个报错信息卡在了什么地方，我理解的是我选择了两个节点，为啥还是有三个节点的报错信息。

是因为极简版报错吗，如果是的话该怎么升为企业版

我可以买来安装包自己部署使用吗？还是只能购买云上数据库实例的哇？

GaussDB轻量化部署版本，什么时候解决视图和表依赖而无法单独修改基表对象的问题，进而实现视图的解耦与重建功能？或者是目前有什么临时解决方案？

       单体数据库时代，随着系统交易量的不断上升，数据库读写性能出现了严重下降。我们可以借助分库分表中间件，比如mycat、shardingjdbc来实现分库分表，缓解单库的读写性能。但是分库分表中间件并不支持事务，如果要保证数据一致性，就需要借助于分布式事务中间件，后来分布式数据库逐渐成为解决数据一致性的选择，目前分布式数据库产品已经比较成熟，支持ACID事务。       而GaussDB是一种高性能分布式数据库系统，针对大规模数据处理和高并发场景进行了优化。 它采用了列存储、分布式计算等先进技术，具有高吞吐量、低延迟的特点。 GaussDB适用于大规模 数据仓库 、 云计算 和 物联网 等场景。相信未来GaussDB会是分布式数据库系统的首选方向。为此大家是怎么看的呢？