关于存储过程中子语句的监控功能即enable_track_record_subsql，8.1.3集群版本中建议不要全面开启，由于没有按时间过滤子语句的功能，全面开启可能会记录过多子语句，导致归档的监控表占用大量磁盘空间；8.1.3集群版本建议仅用于查询实时监控信息，或对个别存储过程业务做定位分析时，仅开启对应会话中的参数。8.2.1版本新增GUC参数resource_track_subsql_duration（默认值为180秒），可以通过执行时间过滤需要归档的子语句，用户可以按需调整该值大小。由于规格限制，对于未下盘的主语句，TopSQL历史表中的记录会有延时，等待下次作业下发时才会显示在TopSQL历史表中。从8.2.1.200集群版本开始，新增operator_realtime级别TopSQL运行时监控，提供算子级实时监控的能力，开启此级别的监控可以查询语句的执行计划以及具体执行信息，查询TopSQL算子级实时监控视图时，默认会显示所有正在执行的语句。但是对于存储过程和游标场景，暂时不支持显示算子级实时监控信息。另由于查询所有语句的信息对于CN内存压力较大，为了不影响作业性能，为用户提供查询单个语句的函数pg_stat_get_wlm_realtime_operator_info(queryid)，可以通过该函数查询指定语句的算子执行信息。

重分布过程中的作业不统计。JDBC执行的带占位符语句，通常会补齐参数内容，但如果参数和原语句合起来长度超过64KB，则不记录参数，或者如果是轻量化语句，直接下发到DN上执行，不记录参数。如果普通语句语句超过64KB，在TopSQL的query字段记录中将被截断。 从8.1.3集群版本开始，query、perf级别TopSQL运行时监控功能已完全不影响查询性能，对当前会话的语句进行资源监控的GUC参数resource_track_cost默认值已修改为0，查询TopSQL实时监控视图时，默认会显示所有正在执行的语句。从8.1.3集群版本开始，对于存储过程中的子语句监控功能，如果在查询TopSQL实时监控视图的会话中，开启控制子语句记录归档功能的GUC参数enable_track_record_subsql，不论业务语句中是否开启子语句监控开关，查询TopSQL实时监控视图的结果都能看到执行语句的子语句运行信息。

记录函数与存储过程的调用入口语句，当GUC参数enable_track_record_subsql开启的情况下，可记录存储过程的部分内部语句(declare定义语句除外)，仅会记录其中下发到DN执行的内部语句，未下发到DN执行的内部语句会被过滤掉；记录匿名块语句，当GUC参数enable_track_record_subsql开启的情况下，可记录匿名块中的部分内部语句，仅会记录其中下发到DN执行的内部语句，未下发到DN执行的内部语句会被过滤掉。记录游标语句，当游标并非从缓存中读取数据，而确实触发语句下发到DN上执行的条件下，该游标语句会被记录，并且会进行语句、执行计划增强，但当游标从缓存中读取数据时，不进行记录；当游标语句在匿名块或者函数中使用时，当游标从DN上读取较多数据但不完全使用时，因当前架构限制，无法记录该游标在DN上的监控信息。对于With Hold游标，该语法执行逻辑特殊，会在事务提交阶段执行实际查询动作，当语句在该阶段执行报错时，作业的aborted状态无法反馈到TopSQL历史表中。

TopSQL不记录白名单和内部语句，但可正常记录超户下发的语句信息，可记录定时任务。query和perf级别的topsql监控主要差异点在于query_plan字段，相比于query级别的算子信息，perf级别的query_plan字段增加算子的实际信息，如算子实际内存峰值，内存自动扩展信息，CU，Buffers等统计信息。query和perf级别实时TopSQL和历史TopSQL的start_time字段信息含义不一致，实时TopSQL中的start_time表示的是作业下发的时间，历史TopSQL中的start_time表示的是作业真正开始运行的时间。查询历历史TopSQL Query，perf以及算子级别数据时，仅能通过postgres数据库进行访问。实时TopSQL中能够记录的SQL语句的规格是：1. 不记录特殊数据定义语句，如：SET、RESET、SHOW、ALTER SESSION SET、SET CONSTRAINTS语句；2. 记录数据定义语句，例如：执行CREATE、ALTER、DROP、GRANT、REVOKE和VACUUM语句；3. 记录数据操作语句，例如：① 执行SELECT、INSERT、UPDATE和DELETE语句。② 执行explain analyze和explain performance场景。③ 使用query级别/perf级别视图。  

在数据仓库服务（DWS）中，备份恢复不仅提供完善的 API 接口，还通过多重技术机制确保数据一致性。一、备份恢复 API 接口的设计与实现1. 华为云 GaussDB (DWS) 的 API 体系核心接口：集群级恢复：通过POST /v1.0/{project_id}/snapshots/{snapshot_id}/actions接口，可指定目标集群的网络配置（VPC、子网、安全组）、端口、公网 IP 等参数，实现快照到新集群的恢复细粒度表级恢复：支持从全量或 Schema 备份中选择单表 / 多表恢复，通过restore-target-list参数指定恢复目标表名，支持覆盖原表或新建表。容灾切换：POST /v1.0/{project_id}/disaster-recovery/{disaster_recovery_id}/switchover接口用于主备集群切换，保证业务连续性。SDK 支持：提供 Java、Python 等多语言 SDK，例如 Java 示例代码如下： RestoreClusterRequest request = new RestoreClusterRequest();RestoreClusterRequestBody body = new RestoreClusterRequestBody();body.setRestore(new Restore() .withName("dws-1") .withSubnetId("subnet-xxx") .withSecurityGroupId("sg-xxx"));request.setBody(body);DwsClient client = DwsClient.newBuilder().build();client.restoreCluster(request); 2. AWS Redshift 的 API 体系核心接口：集群恢复：通过RestoreFromClusterSnapshot API 创建新集群，支持指定 VPC 子网组、KMS 加密密钥、节点类型等参数。无服务器命名空间恢复：支持将备份恢复到 Redshift Serverless 命名空间，通过restore-table-from-snapshot API 实现单表恢复。一致性保障：自动快照策略：默认每 8 小时或每节点数据变化 5GB 时触发增量快照，确保恢复点尽可能接近故障时间。WAL 日志集成：备份时包含事务日志，恢复时通过重放日志保证数据一致性。二、数据一致性的核心保障机制1. 事务日志与全局一致性点华为云 GaussDB (DWS)：XLog 日志：记录所有数据变更操作，备份时结合pg_start_backup()和pg_stop_backup()获取一致性点，确保备份集包含截至该点的所有已提交事务。CBM（Change Block Mapping）：通过常驻线程解析 XLog，实时追踪数据页变更，增量备份仅传输变化的数据块，同时保证恢复时通过日志重放补全未提交事务。AWS Redshift：时间点恢复（PITR）：基于增量快照和 WAL 日志，支持恢复到任意时间点，确保事务完整性。无锁备份：备份过程不阻塞业务读写，通过 MVCC（多版本并发控制）保证数据一致性。2. 物理与逻辑验证结合物理层验证：校验和机制：备份时对数据块计算 CRC32 校验和，恢复时对比校验和确保数据未损坏。存储介质冗余：华为云将备份存储在 OBS（对象存储服务），通过多副本（默认 3 份）保证物理耐久性；AWS Redshift 快照存储在 S3，利用 S3 的跨可用区复制功能。逻辑层验证：ACID 测试模型：华为云采用模拟银行转账场景（C1 + C2 = 100）验证备份恢复的一致性，确保事务原子性和数据完整性。元数据一致性：备份时包含表结构、权限等元数据，恢复后通过 DDL 对比工具验证元数据完整性。3. 增量备份的一致性控制华为云 GaussDB (DWS)：累积与差分模式：累积增量：所有增量基于最近一次全量备份，恢复时只需全量 + 最后一次增量。差分增量：基于上一次备份（全量或增量），恢复时需按顺序应用所有增量。断点续传：备份中断后可从上次暂停的位置继续，避免重复传输数据 AWS Redshift：增量快照链：自动快照形成链式结构，恢复时自动合并全量快照和所有增量，确保数据一致性。4. 加密与访问控制传输加密：华为云通过 TLS 1.3 加密备份数据传输；AWS Redshift 使用 SSL 连接 S3存储加密：华为云支持对 OBS 存储桶启用 SSE-KMS 加密，密钥由用户管理。AWS Redshift 快照默认加密（AES-256），支持使用客户托管的 KMS 密钥权限隔离：华为云通过 IAM 角色控制备份恢复权限，支持细粒度的 API 操作授权AWS Redshift 使用资源策略和 IAM 策略限制快照访问，例如仅允许特定用户恢复到指定 VPC 三、实际应用与最佳实践1. 华为云 GaussDB (DWS) 的典型场景金融交易系统：备份策略：每周日全量备份，每日凌晨增量备份，保留 30 天。恢复验证：每月通过 Roach 工具执行一次模拟恢复测试，对比备份前和恢复后的数据校验和。容灾切换：通过主备集群和灾备切换 API，实现 RPO=0（生产集群可用时）。医疗数据存储：细粒度恢复：仅恢复特定患者的就诊记录，避免全量恢复带来的性能影响。合规性保障：备份日志和恢复记录保存 7 年，满足 HIPAA 等法规要求。2. AWS Redshift 的典型场景电商数据分析：自动快照策略：设置保留期为 7 天，结合 Lambda 函数自动删除过期快照以降低成本。跨区域恢复：将快照复制到其他 AWS 区域，实现跨区域容灾。日志审计系统：单表恢复：通过restore-table-from-snapshot API 快速恢复被误删的日志表，无需恢复整个集群。增量加载：将恢复后的表与当前数据合并，减少业务中断时间。四、选型建议与技术趋势1. 接口易用性对比华为云 GaussDB (DWS)：提供更丰富的细粒度恢复接口（如 Schema 级备份、表级恢复），适合需要精准控制备份范围的场景。AWS Redshift：接口设计更简洁，与 AWS 生态（如 S3、Lambda）集成紧密，适合 Serverless 架构。2. 一致性保障能力华为云：通过 CBM 和 XLog 实现高效增量备份，一致性验证更全面（支持 ACID 测试模型）。AWS：依赖时间点恢复和自动快照链，在大规模数据场景下恢复速度更快。3. 未来技术方向AI 驱动的备份优化：例如华为云正在研究基于机器学习的增量预测，减少备份数据量。联邦备份：跨多个云厂商或数据中心的联合备份，提高容灾可靠性。实时恢复：通过 CDC（Change Data Capture）技术实现秒级恢复，适用于高频交易系统。总结一下下DWS 备份恢复通过标准化的 API 接口和多层次的一致性保障机制，为企业提供了高可靠的数据保护方案。华为云 GaussDB (DWS) 和 AWS Redshift 在接口丰富度、恢复速度和一致性验证上各有优势，企业应根据业务需求（如数据规模、合规性要求）选择合适的方案，并通过定期恢复测试和日志审计确保备份策略的有效性。

811,813版本使用roach工具备份，是什么时候开始有api方式备份的？api接口如何获取？

锁问题定位根据该视图我们可以找到死锁语句，但需要有实时现场，一般发生在客户觉得语句执行慢，或语句返回锁超时，使用以下视图定位。无现场：死锁日志中搜索 deadlock，找到死锁附近日志。复制附近日志，使用死锁工具解析生成死锁关系图    非死锁查看dbmonitor 日志定位排查， pgxc_lock_conflicts 视图，具体字段信息及含义见最后视图表字段说明 有现场：查看等待视图发现有等锁死锁排查死锁  pgxc_deadlock 视图非死锁锁 pgxc_lock_conflicts 视图，查看冲突语句，持锁语句辅助视图及其字段含义pgxc_deadlock 死锁视图，字段如下：名称类型描述locktypetext被锁定对象的类型。nodenamename被锁定对象的节点名称。dbnamename被锁定对象的数据库名称。如果被锁定对象是事务，则为NULL。nspnamename被锁定对象的命名空间名称。relnamename被锁定对象对应的关系名称。如果被锁定对象既不是关系，也不是关系的一部分，则为NULL。partnamename被锁定对象对应的分区名称。如果被锁定对象不是分区，则为NULL。pageinteger被锁定对象对应的页面编号。如果被锁定对象既不是页面，也不是元组，则为NULL。tuplesmallint被锁定对象对应的元组编号。如果被锁定对象不是元组，则为NULL。transactionidxid被锁定对象对应的事务ID。如果被锁定对象不是事务，则为NULL。waitusernamename等待锁的用户名称。waitgxidxid等待锁的事务ID。waitxactstarttimestamp with time zone等待锁的事务的开始时间。waitqueryidbigint等待锁的线程的最新查询ID。waitquerytext等待锁的线程的最新查询语句。waitpidbigint等待锁的线程ID。waitmodetext等待的锁的级别。holdusernamename持有锁的用户名称。holdgxidxid持有锁的事务ID。holdxactstarttimestamp with time zone持有锁的事务的开始时间。holdqueryidbigint持有锁的线程的最新查询ID。holdquerytext持有锁的线程的最新查询语句。holdpidbigint持有锁的线程ID。holdmodetext持有锁的级别。waittimetimestamp with time zone开始等待锁的时间戳。该字段仅9.1.0及以上集群版本支持。holdtimetimestamp with time zone开始持有锁的时间戳。该字段仅9.1.0及以上集群版本支持。pgxc_lock_conflicts 锁等待视图名称类型描述locktypetext被锁定对象的类型。nodenamename被锁定对象的节点的名称。dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULL。nspnamename被锁定对象的命名空间的名称。relnamename被锁定对象对应的关系的名称。如果被锁定对象既不是关系，也不是关系的一部分，则为NULL。partnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULL。pageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULL。tuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULL。transactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULL。usernamename申请锁的用户的名称。gxidxid申请锁的事务的ID。xactstarttimestamp with time zone申请锁的事务的开始时间。queryidbigint申请锁的线程的最新查询ID。querytext申请锁的线程的最新查询语句。pidbigint申请锁的线程的ID。modetext锁的级别。grantedboolean如果锁已被持有，则为TRUE。如果锁还在等待其它锁，则为FALSE。

DWS 线下8115版本集群GBK库中䶮乱码或插入报错 sequence %s in encoding 'UTF8' has no equivalent in encoding 'GBK"，目前线下那个版本GBK库中支持䶮字？

大数据技术未来发展趋势大家怎么看

为什么系统表PG_STATISTIC查不到最近一次analyze的记录？通过那种方式能查到？ 

DWS 已有ntp服务如何修改为chrony服务？

一、问题背景：delete语句执行慢，delete几千条数据，执行要用一分钟，不满足要求。DELETE FROM schema_css.t_call_record_attendee WHERE confuuid in ('xxx','xxx','xxx');表结构：    Column    |          Type           |             Modifiers              | Storage  | Stats target | Description --------------+-------------------------+------------------------------------+----------+--------------+------------- uuid            | character varying(64)   | not null                           | extended |              |  confuuid     | character varying(64)   | not null                           | extended |              |  orguuid      | character varying(128)  |                                    | extended |              |  logicid        | character varying(128)  |                                    | extended |              |  roletype      | character varying(16)   | default 'GUEST'::character varying | extended |              |  displayname  | nvarchar2(512)          |                                    | extended |              |  terminaltype | character varying(32)   |                                    | extended |              |  callnumber   | character varying(128)  |                                    | extended |              |  deptname     | nvarchar2(512)          |                                    | extended |              |  deptuuid      | character varying(128)  |                                    | extended |              |  useruuid      | character varying(128)  |                                    | extended |              |  attribute      | character varying(4096) |                                    | extended |              |  updatetime  | bigint                  | default 0                          | plain    |              |  createtime   | bigint                  |                                    | plain    |              |  deleted        | integer                 | default 0                          | plain    |              | Indexes:    "t_call_record_attendee_pkey" PRIMARY KEY, cbtree (uuid, confuuid) TABLESPACE pg_default    "i_t_call_record_attendee_confuuid" cbtree (confuuid) TABLESPACE pg_default    "i_t_call_record_attendee_logicid" cbtree (logicid) TABLESPACE pg_default    "i_t_call_record_attendee_useruuid" cbtree (useruuid) TABLESPACE pg_defaultHas OIDs: noDistribute By: HASH(confuuid)Location Nodes: ALL DATANODESOptions: orientation=column, enable_hstore_opt=true, enable_binlog=on, binlog_ttl=86400, bucketnums=16384, compression=middle, colversion=2.0, enable_delta=false, enable_hstore=true, enable_turbo_store=true二、问题定位1、无锁冲突，无性能瓶颈，执行的是delete的语句，无法打印执行计划；topsql中记录的是fqs，也没有计划。将delete转化为select语句执行：select * FROM schema_css.t_call_record_attendee WHERE confuuid in ('xxx','xxx','xxx');走FQS执行计划，执行很快；关闭fqs后，走了索引，依然很快，未出现慢的情况。关闭fqs后，打印delete的verbose计划，和select快的计划是一致的，未发现问题。由于FQS计划相当于直连DN执行，因此直连DN打印执行计划，发现也是走了索引的快的计划，性能很快，未能复现。2、根据等待视图，抓取语句堆栈如下：postgres=# select * from pgxc_thread_wait_status where query_id in (select query_id from pgxc_stat_activity where query like '%T_CALL_RECORD_ATTENDEE%'  and usename !='Ruby' order by query_start desc limit 1);  node_name   | db_name |      thread_name       |      query_id      |       tid       |  lwtid  | ptid | tlevel | smpid |           wait_status            | wait_event --------------+---------+------------------------+--------------------+-----------------+---------+------+--------+-------+----------------------------------+------------ dn_6003_6004 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139795727430888 | 3127403 |      |      0 |     0 | none                             |  dn_6009_6010 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 140270667850240 | 4116415 |      |      0 |     0 | none                             |  dn_6011_6012 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139655937670760 | 4116416 |      |      0 |     0 | none                             |  dn_6001_6002 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139846959760552 | 3127402 |      |      0 |     0 | none                             |  dn_6007_6008 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 140166692434008 |  370635 |      |      0 |     0 | none                             |  dn_6005_6006 | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139766594408728 |  370634 |      |      0 |     0 | none                             |  cn_5002      | mms_db  | PostgreSQL JDBC Driver | 145241088536308910 | 139761117827248 | 2735702 |      |      0 |     0 | wait node(total 6): dn_6011_6012 | 3、dn抓堆栈postgres=# SELECT * FROM gs_stack('dn_6001_6002',139846959760552);       tid       |  lwtid  |                                                                            stack                                                                             -----------------+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------- 139846959760552 | 3127402 | texteq(FunctionCallInfoData*) + 0x2                                                                                                                                          |         | ExecEvalScalarArrayOp(ScalarArrayOpExprState*, ExprContext*, bool*, ExprDoneCond*) + 0x41c                                                                                   |         | ExecQual(List*, ExprContext*, bool) + 0x98                                                                                                                                   |         | ExecResult(ResultState*) + 0x7a                                                                                                                                              |         | TupleTableSlot* ExecProcNodeT<false, false, false, false, (NodeTag)201>(PlanState*) + 0x8c                                                                                   |         | ExecRowToVecTupleMode(RowToVecState*) + 0x51                                                                                                                                 |         | VectorEngine(PlanState*) + 0x14a                                                                                                                                             |         | FetchRows(VecModifyTableState*, EState*, CmdType&, PlanState*, PlanState*, JunkFilter*, RelationData*, void*, tagVecModifyTableFuncSet const*, bool) + 0x245                 |         | ExecVecModifyTable(VecModifyTableState*) + 0x1ed                                                                                                                             |         | VectorEngine(PlanState*) + 0x14a                                                                                                                                             |         | ExecVecToRow(VecToRowState*) + 0xda                                                                                                                                          |         | TupleTableSlot* ExecProcNodeT<false, false, false, false, (NodeTag)2000>(PlanState*) + 0x8c                                                                                  |         | standard_ExecutorRun(QueryDesc*, ScanDirection, long) + 0x649                                                                                                                |         | ExecutorRun(QueryDesc*, ScanDirection, long) + 0x375                                                                                                                         |         | ProcessQuery(PlannedStmt*, char const*, ParamListInfoData*, _DestReceiver*, char*) + 0xc9                                                                                    |         | PortalRunMulti(PortalData*, bool, _DestReceiver*, _DestReceiver*, char*) + 0x287                                                                                             |         | PortalRun(PortalData*, long, bool, _DestReceiver*, _DestReceiver*, char*, bool) + 0x583                                                                                      |         | exec_execute_message(char const*, long) + 0x342                                                                                                                              |         | PostgresMain(int, char**, char const*, char const*) + 0x15e4                                                                                                                 |         | SubPostmasterMain(tag_gs_thread_args*) + 0x1209                                                                                                                              |         | MainStarterThreadFunc(void*) + 0x3f                                                                                                                                          |         | ThreadStarterFunc(void*) + 0x40                                                                                                                                             |         | 0x7f323d8dc67a                                                                                                                                                              |         | 0x7f323d95f160                 |         | (1 row)发现堆栈和快的计划对不上，快的计划走了索引，而堆栈中走了全表扫描。4、继续对比复现语句和客户实际业务语句发下，慢的情况是PBE（Prepare-Bind-Execute 预编译）后，参数是通过变量的方式传到条件里的，而复现问题时，条件都是直接写好的。客户的业务语句是通过JDBC绑定变量的方式执行的，形如：DELETE FROM schema_css.t_call_record_attendee WHERE confuuid in ($1, $2, $3);而在复现时，将其中的$1等变量内容替换成了实际常量：DELETE FROM schema_css.t_call_record_attendee WHERE confuuid in (1234, 1235, 1236);怀疑是PBE场景导致的执行计划差异。使用PBE方式直连DN模拟PBE的FQS计划，发现执行计划和抓到的堆栈匹配，问题复现，确认和PBE有关。prepare p1(text,text) as select * FROM schema_css.t_call_record_attendee a WHERE confuuid in( $1, $2);explain verbose execute p1('SFyuC4xX3X7yQHzXqAQxv8md3MHgfoWq','MUZASKbhpDBQwK1A2faPpRzw58qRvV2Z');关闭FQS后，在CN上执行，生成了索引计划，执行性能较快，因此可将关闭FQS作为规避方案set enable_fast_query_shipping=off;prepare p1(text,text) as select * FROM schema_css.t_call_record_attendee a WHERE confuuid in( $1, $2);explain verbose execute p1('SFyuC4xX3X7yQHzXqAQxv8md3MHgfoWq','MUZASKbhpDBQwK1A2faPpRzw58qRvV2Z');5、用户级修改参数alter user xxx set enable_fast_query_shipping=off;中间有一个小插曲是，用户级修改参数后，新建连接立即生效，不需要重启，但是老连接不生效，因此需要用户新建连接测试规避方案是否有效。可以通过审计日志查看用户登入登出时间，确保在参数调整后新建连接：select * from pgxc_query_audit('2025-08-15 00:00:00','2025-08-15 06:30:00') where session_id like '%对应的pid%' and detail_info not in ('START TRANSACTION','ROLLBACK','COMMIT') and operation_type ='login_logout' order by begintime;修改参数生效后，验证问题得到解决。 三、问题根因通过PBE的方式执行，array用法在PBE场景下不支持向量化，in条件会被转化为array，直接执行时，走的FQS计划，导致走了全表扫描，再走行存过滤表达式，性能差。关闭FQS后，变量在CN上被替换，替换后支持向量化，因此可以生成索引扫描计划，性能快。规避方法：（1）通过hint关闭fqs ： /*+ set global(enable_fast_query_shipping off) */，仅影响当前语句（2）用户级关闭参数： alter user xxx set enable_fast_query_shipping=off;  仅影响当前用户，一般不会产生其他副作用 

云计算未来发展趋势大家怎么看

GaussDB(DWS)的技术优势cid:link_0声明式查询语言cid:link_8单个未索引属性cid:link_1多属性过滤cid:link_2MPP的分布式数据仓库cid:link_3逻辑集群架构cid:link_9逻辑集群的隔离性cid:link_10物理集群cid:link_4逻辑集群用户cid:link_11非逻辑集群用户cid:link_12逻辑集群的使用场景cid:link_5逻辑集群下SQL语法和兼容性cid:link_6TopSQL相关视图与GUC参数cid:link_7RESOURCE资源cid:link_13TopSQL视图字段https://bbs.huaweicloud.com/forum/thread-0228191133868088068-1-1.html

因数据量变化，导致作业执行时间增加，可以分析A2/B1/D1/G1，进而确认作业查询的数据表是否有明显的数据量增加；由于目前历史TopSQL视图字段信息较多，建议使用PGXC_QUERY_INFO视图查看查询经典字段信息，无需手动过滤无关字段。因其它并发作业抢占，导致作业排队，从而导致作业执行时间增加，可以分析A1/B1/D1，进而查看作业执行的同时期是否有大量并发作业在执行；因其它作业而产生的CPU抢占，导致作业执行时间增加，可以分析A2/D1/E1，进而查看作业执行的同时期是否有大量并发作业在执行；因其它作业而产生的IO抢占，导致作业执行时间增加，可以分析A2/F1，进而查看作业执行的同时期是否有大量并发作业在执行；禁止某一类语句执行，可参考H1。值得注意的是，发生资源争抢时，可能会出现并发症，即CPU、IO抢占，作业排队现象都会发生，针对并发症问题，可以逐步分析解决，比如：第一步，调整作业执行顺序，减少并发作业数量，减少阻塞时间；第二步，定位出同时段执行的典型计算密集型、存储密集型作业，先移动到其它时间段执行，减少对本作业的影响；第三步，在无其他作业明显干预的情况下，做进一步分析。