通信协议不匹配问题cid:link_2语句出错怎么排查cid:link_3认识数据库视图对象cid:link_4数据库视图提供了额外的安全层cid:link_5视图对表结构的依赖cid:link_6GaussDB(DWS)常用系统视图cid:link_7视图解耦cid:link_8底层对象改变，视图置为无效cid:link_9无效视图使用，视图刷新有效cid:link_10如何递归查询视图依赖cid:link_11了解HiveMetaStorecid:link_0external schema与schema的区别cid:link_12创建EXTERNAL SCHEMAcid:link_13GUC参数调优cid:link_1enable_sort参数https://bbs.huaweicloud.com/forum/thread-0259181318729277041-1-1.html

GaussDB(DWS)中实现分组聚集操作有两种方法：HashAgg：使用Hash表对数据进行去重，并同时进行聚集操作，适用于聚集后行数缩减较多的场景。Sort + GroupAgg：首先对数据进行排序，然后遍历排序后的数据，完成去重和聚集操作，适用于聚集后行数缩减较少的场景。如果使用Sort + GroupAgg的方式，在Sort排序算子里执行时间比较长，因为需要对大量数据进行排序操作。GaussDB(DWS)中通过count distinct来统计多个列的数据时，通常会使用HashAgg来实现每一个列的统计聚集操作，然后将结果通过Join方式关联起来得到最终结果。从查询计划来看，通过count distinct统计了lineitem表中的6列数据，是通过6个HashAgg操作来实现的，该SQL执行时消耗的资源相对较高。如果关闭enable_hashagg参数，优化器会选择Sort + GroupAgg的方式，该SQL执行时消耗的资源相对较少。在应用开发时，可以根据SQL并发和资源使用情况，通过设置enable_hashagg参数来选择合适的执行计划。

系统级调优中数据库全局的GUC参数对整体性能的提升至关重要，而在语句级调优中GUC参数可以调整估算模型，选择查询计划中算子的类型，或者选择不同的执行计划。因此在SQL调优过程中合理的设置GUC参数十分重要。查询计划的生成是基于一定的模型和统计信息进行代码估算，在某些场景由于统计信息不准确或者代价估算有偏差时，就需要通过GUC参数设置的的方式选择更优的查询计划。在GaussDB(DWS)中，和SQL执行性能相关的GUC参数主要有以下几个：best_agg_plan: 进行聚集计算模型的设置enable_sort: 控制优化器是否使用的排序，主要用于让优化器选择使用HashAgg来实现聚集操作enable_hashagg：控制优化器是否使用HashAgg来实现聚集操作enable_force_vector_engine：开启参数后强制生成向量化的执行计划query_dop：用户自定义的查询并行度GaussDB(DWS)是分布式的数据库集群，数据计算尽量在各个DN上并行计算，可以得到最优的性能，在Stream框架下Agg操作可以分为两个场景。Agg下层算子输出结果集的分布列是Group By列的子集这种场景，直接对下层结果集进行汇聚的结果就是正确的汇聚结果，生成算子直接使用即可。例如以下语句，lineitem的分布列是l_orderkey，它是Group By的列。Agg下层算子输出结果集的分布列不是Group By列的子集。对于这种场景Stream下的聚集（Agg）操作，优化器可以生成以下三种形态的查询计划：hashagg+gather(redistribute)+hashaggredistribute+hashagg(+gather)hashagg+redistribute+hashagg(+gather)

GaussDB(DWS) 通过external schema 对接HiveMetaStore，映射到对应的外表元数据，再通过外表访问 Hadoop。SQL查询：select查询形式为 select * from ex.tbl，其中tbl为外源表名，ex为已创建的external schema。语法解析：语法解析层主要针对进行解析，主要负责以下内容：当读取到ex.tbl表以后，连接HMS进行元数据查询。元数据查询：从HMS中查询元数据信息。从HMS中读取数据，主要包括列信息，分区信息、分区键信息、分隔符信息等。数据查询（针对select）：从DFS存储中获取统计信息文件个数和文件大小，为plan生成提供依据。查询重写、查询优化、查询执行查询下发：将元数据随plan下发给DN，DN收到plan以后，会将元数据进行解码后插入到SysCache中。查询执行：DN访问obs对应文件，执行查询。获取Hive的metastore服务内网IP和端口以及要访问的Hive端数据库名称。登录MRS管理控制台。选择“集群列表 > 现有集群”，单击要查看的集群名称，进入集群基本信息页面。单击运维管理处的“前往manager”，并输入用户名和密码登录FI管理页面。依次单击“集群”、“Hive”、“配置”、“全部配置”、“MetaStore”、“端口”，记录参数hive.metastore.port对应的值。依次单击“集群”、“Hive”、“实例”，记录MetaStore对应主机名称包含master1的管理IP。。

external schema主要用于与HiveMeatStore建立连接，获取表对象元数据，在创建external schema时需要指定连接的所需要的各个属性值。普通schema在创建后会将schema的信息记录在pg_namespace中，external schema创建后和普通schema一样也会记录在pg_namespace，可以通过pg_namespace中的nsptype字段区分是external schema还是普通schmea。用户在使用本特性前，将需要创建Server，创建Server过程与已有Server创建过程相同对于创建OBS server有两种方式，一种是通过永久AK、SK的方式创建。（此种方式前提是可以获取永久AK、SK，但是此种方式不安全，AK/SK直接暴露在配置文件中，并且创建服务的时候需要明文输入AK、SK，不建议采用此种方式创建服务）另一种云上DWS绑定ECS委托方式访问OBS，通过管控面创建OBS server。委托通过管控面创建server可参考创建外表时如何创建OBS server。其中SOURCE字段指定了外部元数据存储引擎的类型，DATABASE为Hive中对应的数据库名，SERVER为创建的server，METAADDRESS为Hive提供的地址端口信息，CONFIGURATION为Hive、Kerberos相关配置文件路径。external schema的目标是对接外部元数据（Foreign Meta），使得DWS能主动感知外部元数据的变化。

在大数据融合分析时代，面对海量的数据以及各种复杂的查询，性能是我们使用一款数据处理引擎最重要的考量。而GaussDB(DWS)服务有着强大的计算引擎，其计算性能优于MRS服务中的hive或者spark这类计算引擎，且可以以更低的成本满足业务高弹性和敏捷性需求。通过与MRS联动，无需搬迁数据，利用DWS的高性能计算引擎处理和分析数据湖中的海量数据以及各种复杂的查询业务、分析业务越来越成为主流的解决方案。我们可以通过创建external schema的方式来对接HiveMetaStore元数据服务，从而实现GaussDB(DWS)直接查询hive/spark表或者插入数据到hive/spark表。无需创建读外表或者写外表，也无需担心hive/spark表的定义发生变化时GaussDB(DWS)没有及时更新表定义。HiveMeatStore是Apache Hive的一个关键组件，它是一个元数据存储库，用于管理hive/spark表的元数据信息。HiveMeatStore存储了Hive表的结构信息，包括表名、列名、数据类型、分区信息等。它还存储了表的位置信息，即表数据存储何处。HiveMeatStore的主要作用是提供元数据服务，使得Hive/Spark可以对数据进行查询和分析。它还提供了一些API，可以让开发人员通过编程方式访问表的元数据。总之，HiveMeatStore是Hive的一个重要组件，它提供了元数据管理和查询服务。external schema即外部模式，GaussDB(DWS)通过创建extrenal schema来对接HiveMeatStore服务，每次查询主动获取hive/spark表对象的元数据。无需GaussDB(DWS)内核通过create foreign table获取hive/spark表的元数据。

对于postgres生态来说，视图的依赖关系没有现成的查询方法，需要对系统表pg_depend及pg_rewrite编写复杂的组合查询才能得知，而对于Oracle和MySql，该需求都较易实现，分别查询USER_DEPENDENCIES和INFORMATION_SCHEMA.VIEWS即可轻易查出，因此在pg生态来说有必要编写一个直观的视图来查看各个视图与基表或与其他视图的层级依赖关系。可见这种查询并不直观，只能通过肉眼分析得出递归的依赖关系，对用户并不友好。例如起名为PUBLIC.gs_view_dependency。接下来我们来学习一下with recursive语法的使用方法，从pg官网可以get到的知识是，WITH语句通常被称为通用表表达式（Common Table Expressions）或者CTEs。WITH语句作为一个辅助语句依附于主语句，WITH语句和主语句都可以是SELECT，INSERT，UPDATE，DELETE中的任何一种语句。WITH语句还可以通过增加RECURSIVE修饰符来引入它自己，从而实现递归。WITH RECURSIVE语句包含了两个部分（非递归部分）non-recursive term，即上图中的union all前面的部分（递归部分）recursive term，即上图中union all后面的部分执行步骤如下：执行non-recursive term。（如果使用的是union而非union all，则需对结果去重）其结果作为recursive term中对result的引用，同时将这部分结果放入临时的working table中重复执行如下步骤，直到working table为空：用working table的内容替换递归的自引用，执行recursive term，（如果使用union而非union all，去除重复数据），并用该结果（如果使用union而非union all，则是去重后的结果）替换working table。

对于无效视图处理方式，在不同版本之间行为不同，具体差异如下：在8.1.0版本中，无效视图不能使用，需要先执行ALTER VIEW view REBUILD或CREATE OR REPALCE将视图刷新为有效状态在进行操作，过程中需要对该视图及下层无效视图加八级锁；在8.1.1版本中，无效视图查询时同时尝试刷新视图，内部调用ALTER VIEW ONLY view REBUILD语法，对本视图及下层视图做重建，重建过程中对该视图及下层无效视图加八级锁后更新系统表；在8.2.1版本中，无效视图做本地展开（相当于将视图作为一个子查询），本地重建时对该视图及下层视图持一级锁且不更新系统表，视图可正常使用。GaussDB(DWS)视图解耦功能的发展历程以及现有所支持的操作，在总结现在已有的功能的过程中，详细阐释了视图有效状态和无效状态切换时的持锁情况及行为逻辑，展示了视图相关的系统视图作用和效果，对比了友商与我们之间的行为差异。视图解耦功能通过view_independent参数控制，默认关闭。开启后，存在视图依赖的基表或其他数据库对象（如视图、同义词、函数、表字段）可以单独删除（临时表及临时视图除外），关联视图保留但不可用。

为保证实现底层对象和视图之间的解耦且视图定义可以存在，在打开视图解耦后，对视图所依赖的底层对象做以下DDL操作,ATLER TABLE DROP COLUMNATLER TABLE ADD COLUMN(只有视图依赖对象的RECORD类型时)ATLER TABLE COLUMN TYPEALTER TABLE/VIEW SET SCHEMARENAME COLUMN/TABLEDROP TABLECREATE OR REPLACE VIEW/FUCNTION需要将视图依赖关系链中的所有视图标识为无效状态，其定义在pg_rewrite系统表中的ev_enabled字段（'O’为正常，'D’为无效），该标识用于以后续对无效视图的处理。当底层对象发生改变时，上层视图均会置为无效的状态。如果在依赖关系中，中间的视图发生变化，只有其上层视图会被置为无效，也就是说，当该视图无效时，其上层视图也必然是无效的。我们在业务中经常存在这种场景，一个视图依赖于两个及以上底层对象，此时在对底层对象分别做DDL操作时，因为都需要将上层视图置为无效状态，所以会导致另外一个对象锁等待周期过长的问题，无法并发执行。

GaussDB(DWS)数仓产品内部使用对象标识符(oid)来保存对象之间的引用关系，这使得视图在定义时就绑定了其依赖的基表的oid。如果要删除字段或整个表，就需要连同其关联的视图一起使用cascade关键字删除，表修改完成后再重建各级视图，这就给用户的使用增加了很大的工作量。为了解决这一问题，GaussDB(DWS) 在8.1.0版本实现了视图的解耦，8.1.1版本在此基础上又实现了自动刷新，8.2.1版本实现了本地自动刷新，避免了自动刷新时持锁周期过长、持锁粒度过大的问题。GaussDB(DWS)数仓产品内部使用对象标识符（oid）来保存对象之间的引用关系，这使得视图在定义的时候就绑定了其依赖的数据库对象的oid，而不管其名称怎么改变，都不会改变这层依赖关系。如果要对基表进行一些字段修改，会因为与视图字段存在强绑定而报错，如果要删除某个表字段或整个表，就需要连同其关联的视图一起使用cascade关键字删除，表字段删除完成或表重建后再顺序重建各级视图，这就给用户的使用增加了很大的工作量，相对于某些市场主流数仓产品存在明显的易用性差异。为了解决这一问题，GaussDB(DWS) 实现了视图的解耦，使得存在视图依赖的基表或其他数据库对象（视图、同义词、函数、表字段）可以单独删除，而其上关联的依赖视图依然存在，而在基表重建后，可以通过ALTER VIEW [ONLY] view_name REBUILD命令重建依赖关系。不同版本之间对于视图解耦功能的优化。

GaussDB(DWS)还提供了许多视图用于展示数据库的内部状态，以下几个视图，在定位故障时会经常使用。pg_stat_activity：用于查询当前实例上各个Session的状态。pg_thread_wait_status：用于查询该实例上各个线程的等待事件。pg_locks：用于查询当前实例上的锁状态。pgxc_lock_conflicts：提供集群中有冲突的锁的信息，当某一个锁正在等待另一个锁，或正在被另一个锁等待，即该锁是有冲突的。pgxc_deadlock：获取导致分布式死锁产生的锁等待信息。存在一系列与 Workload 控制组内 SQL 语句执行次数和响应时间统计相关的视图，如显示当前节点上 Workload 控制组内的 SQL 语句执行次数统计信息的视图，以及显示集群中所有 CN 节点上 Workload 控制组内 SQL 语句执行的响应时间统计信息的视图等，能够帮助用户了解不同类型 SQL 语句的执行情况，便于性能调优和监控。这些系统视图可以帮助用户和管理员更好地管理和监控 GaussDB (DWS) 数据库，了解数据库的运行状态、用户信息、对象结构等方面的信息。具体使用时，可以根据实际需求进行查询和分析。

由于视图时根据数据库的基础表创建的，每当更改与视图关联的那些表的结构时，也必须更改视图。GaussDB(DWS)在8.1.0版本实现了视图的解耦，使得存在视图依赖的基表或其他数据库对象（视图、同义词、函数、表字段）可以单独删除，而其上关联的依赖视图依然存在，而在基表重建后，可以通过ALTER VIEW view_name REBUILD命令重建依赖关系。而8.1.1版本在此基础上又实现了自动重建，可以无感知自动重建依赖关系。在GaussDB(DWS)上，当开启视图可更新参数（enable_view_update）后，系统允许对简单视图使用INSERT，UPDATE、DELETE和MERGE INTO语句进行更新，满足以下所有条件的视图可进行更新。视图定义的FROM语句中只能有一个普通表，不能是系统表、外表、dfs表、delta表、toast表、错误表。视图中包含可更新的列，这些列是对基础表可更新列的简单引用。视图定义不能包含WITH、DISTINCT、GROUP BY、ORDER BY、FOR UPDATE、FOR SHARE、HAVING、TABLESAMPLE、LIMIT、OFFSET子句。视图定义不能包含UNION、INTERSECT、EXCEPT集合操作。视图定义的选择列表不能包含聚集函数、窗口函数、返回集合的函数。视图上不能有触发时机为INSTEAD OF的触发器。视图定义不能包含子链接。视图定义不能包含属性为VOLATILE的函数（函数值可以在一次表扫描内改变的函数）视图定义不能对表的分布键所在列起别名，或将普通列起别名为分布键列名。视图更新操作中包含RETURNING子句时，视图定义中的列只能来自于基础表。

安全性是任何关系数据库管理系统的重要组成部分，数据库视图为数据库管理系统提供了额外的安全性。数据库视图允许创建只读视图以向特定用户公开只读数据，用户只能在只读视图中检索数据，但不能对其进行更新。数据库表中不应该有计算列，但是数据库视图支持有计算列。假设在订单表中有订购产品的数量和每个产品的价格列，但是订单表定义一列来存储每个订单的总销售额。如果有，这样的数据库模式也不是一个好的设计。在这种情况下，可以创建一个名为总销售额的列， 它是计算结果是产品的价格乘以订购产品的数量。当从数据库视图查询数据时，计算列的数据会动态进行计算。假设有一个核心数据库，许多应用程序都在使用它，为了适应新的业务需求，有可能会重新设计数据库，删除了一些表并创建了几个新表，修改表的列名，此时并不希望这些更改影响之前的应用程序。在这种情况下，可以使用与已删除的旧表相同的表结构创建数据库视图。应用程序可以访问视图来完成此前功能，这样就无需对应用程序做任何的修改。从传统数据库视图查询数据可能会很慢，特别是如果视图是基于其他视图创建的。GaussDB(DWS)通过对视图解析和查询优化，生成的查询计划基于基础表，依然可以提供高效的查询性能。

当用户对数据库中的一张或者多张表的某些字段的组合感兴趣，而又不想每次键入这些查询时，用户就可以定义一个视图，以便解决这个问题。视图中列可以来自于表里的不同列，这些列都是用户所感兴趣的数据列。视图与表不同，它在物理上不是真实存在的，而是一个虚表。在数据库里仅存放视图的定义，而不存放视图对应的数据。视图中的这些数据存放在其对应的表中，如果表中的数据发生了变化，从视图中查询出的数据也会随之发生改变。从这个意义来看，视图就像一个窗口，透过它可以看到数据库中用户感兴趣的数据及变化。每一次查看视图或引用视图的的时候，都会运行一次视图上的查询。用户可以使用SELECT语句从视图里查询数据，对于符合一定约束条件的视图，还可以使用INSERT、UPDATE、DELETE、MERGE INTO等语句修改视图对应的基础表里的数据。视图在提供操作方便的同时，还可以保障数据库数据的安全。数据库视图由许多基础表相关联的 SQL 语句定义，可以使用数据库视图向最终用户和外部应用程序隐藏底层表的复杂性。通过数据库视图，只需要使用简单的 SQL 语句，不需要编写具有许多连接的复杂语句。如果不希望所有用户都可以查询敏感数据，就可以使用数据库视图仅向特定用户组公开非敏感数据。

运行过程中出错，ODBC是不会打屏的。错误信息需要业务里获取错误信息（API为：SQLGetDiagField/SQLGetDiagRec）。 如果用户的业务里有打印具体的错误信息，或者业务的错误信息不足以定位，请根据3.7中的描述，将ODBC的日志打印出来，在其中找SQL_ERROR相关信息。这里最好能和业务开发人员一起定位，因为API的调用序列是乱序的，由业务决定。 如果ODBC的日志仍然不足以定位支撑，请登录到连接的目标CN所在的机器，通过以下方法进入CN日志文件目录：source ${BIGDATA_HOME}/mppdb/.mppdbgs_profilecd $GAUSSLOG/pg_log/cn_50xx #这里的cn_50xx表示CN编号，根据实际情况修改找到对应时间点的日志，观察其中是否有错误信息。 我们ODBC驱动默认使用utf-8编码。如果要调整，需要自行在会话开始时设置client_encoding。 但是请注意，请不要在宽字节模式下使用GBK，因为宽字节编码本身就是UNICODE的一部分（一般为UCS2），此时使用GBK可能导致数据无法显示，SQL查询结果不正确等问题。