根据作业的sql_hsah信息确定作业的历史执行情况，借助历史TopSQL的资源信息和query_plan字段分析作业性能劣化原因。找到对应的快慢语句后，对比其执行计划query_plan，发现执行计划跳变严重。对相应的表做analyze后，恢复合理计划，语句性能恢复。统计信息不准，导致计划跳变，是十分常见语句变慢原因，analyze不影响读写，遇见语句变慢可预先做analyze。作业长时间运行不结束在作业无排队无死锁正常运行期间，发现作业长时间不结束，此时可查看算子级别的实时TopSQL监控，能够看出哪个算子执行时间长，通过算子执行时间和已处理行数等信息，确定是否需要查杀SQL。开启实时算子监控：set resource_track_level = 'operator_realtime';当发现作业内存整体使用较高，query级别的TopSQL无法记录算子的实际资源信息，此时可以设置TopSQL的监控级别为perf，query级别与perf级别的TopSQL差异主要在query_plan，perf级记录更详细执行信息，较query级性能损耗5%以内，perf级别的TopSQL的query_plan字段可显示算子的时间actual_time，memory，rows和buffer等信息。

作业下发执行后，内核通过打桩记录作业的各项资源信息，如内存、CPU、下盘、IO和网络信息等，作业执行完成后该资源信息后先存在无锁队列中，资源管理后台辅助线程将该数据信息定期转储到dbms_om.gs_wlm_session_info系统表中，后续通过topsql_retention_time定期老化数据。通常情况下，TopSQL记录的信息较多， 查询时可使用start_time做条件，避免全表查询，且使用limit对结果集大小限制，防止结果集过大导致客户端OOM。通过TopSQL历史视图查询到有10+业务SQL存在stream数超过100，判断为CPU高的原因。因为topsql记录了一些语句的执行情况和资源消耗情况，在定位性能问题的时候非常有帮助，比如周期执行的sql，突然有一天变慢了，我们可以通过分析语句的执行时间和阻塞时间判断是语句被阻塞了（排队等）还是执行的慢了，通过记录的执行计划分析语句为什么慢了，是不是当时的统计信息统计不准，还是没有对表做analyze，也可以看下盘量大小分析是不是下盘量大造成的性能变慢。通过pgxc_wlm_session_info视图确认历史的SQL信息（注：历史topsql视图按天分区，查询时尽量带start_time条件）。

不同视图从不同维度统计业务在数据库中的运行状态，因为或多或少都包含部分同类字段，可用于后续关联分析，此处给出历史TopSQL视图常交互的其他视图：使用示例：如果某个语句在历史TopSQL 历史pgxc_wlm_session_info视图中显示以往该作业很快就能正常运行完成，但是此时查杀pgxc_stat_activity发现该语句运行很长时间没有结束，则此时可能有异常，可利用以下步骤进行定位。查询pgxc_stat_activity活跃视图，找出长时间运行不结束的异常作业。根据步骤1得到的query信息，查询历史TopSQL视图，比较以往和现在的运行情况，如果以前运行时间很快，但当前语句运行时间很长未结束，则可考虑该语句已发生异常（历史topsql视图按天分区，查询时尽量带start_time条件）。根据步骤1得到的query_id查询等待视图pgxc_thread_wait_status，得到作业线程号lwtid，并打出作业堆栈进行分析。  

在SQL执行过程中，有些用户更希望能对算子执行进度进行监控，对于长时间运行的SQL，能够看出哪个算子执行时间长，通过算子执行时间和已处理行数等信息，确定是否需要查杀SQL，此时需要将RESOURCE_TRACK_LEVEL参数设置为OPERATOR。算子监控可以将SQL执行过程的算子监控数据以可视化的方式呈现出来，以便用户更加直观地了解算子的运行情况和性能表现。算子监控主要有以下价值：提升用户体验：通过可视化的方式呈现算子执行信息，用户可以更加直观地了解算子的运行情况和性能。性能优化：通过对算子监控数据的可视化分析，可以发现算子运行中的瓶颈和问题，从而及时进行优化和调整，提高算子的运行效率。故障排查：通过对算子监控数据的可视化分析，可以及时发现算子运行中的问题和异常，从而及时进行修复和维护，提高SQL的可维护性。提高算子的可扩展性：通过对算子监控数据的可视化分析，可以发现算子运行中的瓶颈和问题，从而及时进行优化和调整，提高算子的可扩展性，为后续的业务发展提供支持。OPERATOR算子监控和QUERY/PERF语句监控功能类似，均包含实时和历史二种形态，包含静态和动态二类信息：语句静态信息是语句在真正执行前就已经由优化器生成的信息，如执行计划plan_node_name，queryid，预估行数estimated rows等信息。可用来分析生成的执行计划是否合适。语句动态信息是语句在执行器中执行过程中所占用的资源信息，如算子执行进度progress、内存peak_memory、算子下盘spill_size、网络net_size、磁盘IO(read_bytes、write_bytes)，CPU（cpu_time）等不同DN的实时的信息记录。可用来分析语句执行过程中的进度和资源消耗情况，通过该字段可以分析出语句在运行是消耗较久的在什么地方，便于后续优化。

operator_realtime级别TopSQL运行时监控对于CN轻量化和存储过程的情况，暂时不支持。另由于算子执行速度较快的原因，对于算子信息的显示会有一定滞后性。query级别的作业监控和operator的算子监控中的spill_size字段，由于统计维度不同，会有一定差异，query级别监控监控的语句实际下盘文件大小，算子监控的是具体算子在逻辑层IO读写的数据量。当GUC参数enable_stream_operator设置为off状态时，算子执行信息存在显示不准的情况。在813版本中，除初始用户外，enable_gtm_free开启且关联队列不管控情况下，用户作业不进入资源管控。此时实时与历史TopSQL均不记录该用户下发的作业。现网中有概率出现某一个SQL原先执行比较快，后来发现该语句执行时间变长，此时就需要利用TopSQL中的query_plan以及其他资源信息进行分析定位，毋庸置疑，query_plan中的信息越详细，越接近于explain performance，定位过程就更容易。query级别与perf级别的TopSQL差异主要在query_plan，perf级记录更详细执行信息，较query级性能损耗5%以内，perf级别的TopSQL的query_plan字段可显示算子的时间actual_time，memory，rows和buffer等信息。

关于存储过程中子语句的监控功能即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的记录？通过那种方式能查到？