SysCache对外接口主要包括两个： 查询SysCache和释放SysCache，这两个方法需要配对使用，在SysCache返回查询结果后，需要再次调用释放SysCache接口，以释放SysCache相关数据。 在查询SysCache前，需要确保CatCache初始化，之后，需要依据查询的key信息计算哈希值，以定位哈希桶位置。对于SysCache而言，数据的key最多为4个，在上述例子中，key1=public，key2=abc，key3和key4将以0进行补全。 计算哈希值之后，将扫描对应哈希桶中的双向链表，逐个进行匹配，若未匹配到，将进一步扫描该系统表的数据页。若数据页中也没有该数据，则说明不存在该数据，需要建立一个假的CatCTup，并标记为negative，以提升查询miss效率，若数据页中包含该数据，则将该条数据进行封装，建立CatCTup，并插入到对应的哈希桶中。 在匹配到CatCTup后，需要将当前CatCTup的引用数量refcount加一，并进行返回，refcount的作用是计数引用，以防止被错误释放。 对于释放SysCache，其主要步骤是将引用数量refcount减一，并释放refcount为0的资源。

GaussDB(DWS)在处理用户查询请求过程中，会频繁访问表相关元数据，那么如何在不损失性能的前提下快速访问表元数据呢？答案是建立Cache。DWS在针对系统表数据和表定义分别建立了两套不同的Cache体系，SysCache主要针对系统表，对系统表中访问频繁的记录进行缓存，以达到性能提升的目的；RelCache主要针对表定义，包括所有用户表和系统表进行缓存。虽然简单执行了一条insert语句，其中涉及到的解析、校验逻辑是异常复杂的，会关联大量系统表相关查询操作。为了加快系统表查询速率，GaussDB(DWS)中针对系统表查询操作构建了SysCache缓存，以加速系统表查询速率。在上述例子中，语句b)在执行时，会访问相关系统表元数据，并通过SysCache进行缓存，之后在语句c)和语句d)执行时，直接从SysCache获取相应的缓存信息，以加速执行效率。SysCache在内存中以指针数组的形式进行存储，数组中每个元素均为一个CatCache结构体，CatCache中存储了系统表中的元数据信息。在CatCache中可能存在大量被缓存的数据，为加速查找，CatCache中设计了哈希数组，哈希数组包含多个哈希桶，每个哈希桶中记录了元数据链表信息，最终元数据是以双向链表的形式存于哈希桶中的。

资源池队列阻塞告警是基于DMS原有告警功能进行实现，实现流程依旧是分为数据上报与采集—>告警判断—>上报告警。信息采集线程会将资源池中任务的状态实时上报，形成原始指标落盘，然而我们需要判断不同优先级的任务排队情况，直接用原始数据进行处理会比较繁琐，所以我们借助一个定时任务，定时采集原始指标数据，并进行整合、转置，最后我们用整合后的数据，判断是否发生了资源池阻塞。 如果用户设置的资源池并发数过小，会出现资源池队列排队，此时应当调大资源池并发数量。 资源池通过绑定控制组进行实现资源的分配，作业的优先级和其关联的资源池的资源数量有关。一般情况下，我们认为作业关联到的资源池拥有的资源数量越多，则其优先级越高，因为该作业能够拥有更多的资源去执行。如果一个资源池拥有的资源比例发生了变化，则其对应的优先级也会发生变化，可以通过调整资源池中属性来修改优先级。 在开启资源负载管理功能之后，default_pool是由系统自动创建，当一个会话或者用户没有指定关联的资源池时，都会被默认关联到default_pool，并且default_pool默认绑定到DefaultClass:Medium控制组，并且不限制所关联的业务并发数，而且一个控制组可以绑定多个资源池。

影响作业在资源池运行的要素有并发数、CPU和内存等资源限制，也可能是由于集群状态异常导致的，下面我们将从以下两种情况进行分析。 第一种情况，如果并发或CPU等资源不够用，会出现资源池队列排队，但并非阻塞的状态，因为作业结束后，处于队首的作业会开始运行，那么资源池队列中的作业是动态变化的。 第二种情况，如果用户下发的作业就是特别的复杂，运行时间可能有几十分钟，那么在默认情况下，资源池队列中的作业始终不变，但是如果用户在调整作业优先级之后，作业能够正常运行，也不能说明资源池是阻塞的。 结合以上两种情况，我们结合资源池队列中作业的状态，以及不同优先级作业在资源池的运行情况判断资源池是否阻塞。首先我们将范围限定在默认资源池中，因为默认资源池是开启资源管理功能后又系统创建，代表系统的状态；其次资源池执行任务异常，必定引起资源池队列出现排队现象，且处于队首的任务始终不变，排队时间增加；并且运行在资源池上所有优先级的作业都不能正常下发。 总结下来就是，在一定时间内，集群默认资源池队列中处于各个优先级的作业不变即可判定为资源池队列发生阻塞。

当一个控制组关联的资源池有多个的时候，用户下发的作业应该使用哪个资源池来执行任务呢？如果用户已经下发了很多作业，但是某个新作业又非常紧急怎么办？类似的问题可能还有很多，那么如何解决上述的问题呢，这时候我们就要借助一个手段：query band。 GaussDB(DWS)实现基于query band的负载识别和队列内优先级控制，一方面提供了更为灵活的负载识别手段，可根据作业类型、应用名称、脚本名称等识别负载队列，使用户根据业务场景可灵活配置query band识别队列；另一方面实现了队列内作业下发优先级控制。管理员用户可根据业务场景及作业类别配置query_band所关联队列及估算内存限制等实现更为灵活的负载控制与资源管控。 query_band支持关联作业优先级，支持高中低(High/Medium/Low)三个优先级，同时提供Rush作为特殊优先级，默认优先级为Medium。 如果业务未配置query band或用户未将query band关联行为时，作业会默认使用用户关联队列和队列内优先级。 从上述的介绍可以理解为，query band可以设置任务在资源池中的执行顺序，优先级高的任务优先执行；如果出现资源不足等不能立刻执行任务的情况，则会触发排队优先级，优先级高的优先在队列中排队。

DWS的负载管理分为两层，第一层为CN的全局并发控制，第二层为资源池级别的并发控制。在通过第一层控制的时候，会继续向前走到第二层资源池控制，根据资源池当前的负载资源情况决定作业继续执行或者排队。影响一个集群的资源包括内存、CPU、磁盘I/O和存储空间等。GaussDB(DWS)提供了一系列资源负载管理手段，通过对资源的集中管控，可以有效避免作业占用资源的冲突，高优先级作业优先执行，以及用户间的资源隔离。负载管理是为了解决排队的问题，将任务能够平均到不同的cn或资源池上；然而在实际应用中，作业是否排队与资源池的资源有着直接关系；资源管理通过一定手段提高资源的利用率。

监控数据库，必须要对数据库各指标数据进行采集，通过合理的统计查询，获得实时或周期性的数据库和集群的状态，结合告警策略触发告警。修改绑定集群可以设置次告警规则适用的集群范围，默认为全部，可多选。修改阈值可以调整触发告警的上限或下限，每种指标默认提供了阈值范围，可按照页面提示和实际情况进行合理修改。修改持续周期，可以拉长或缩短指标数据的查询范围，检测的是长周期的指标变化趋势，还是某时刻的指标异常变化。修改抑制条件可以控制告警的发送频率，处于抑制期的告警不会重复发送。DMS告警框架还在建设当中，后续还会提供更多的监控指标，支持多种策略配置方式，告警框架后续也会与系统的功能模块联动起来，让监控系统更“智能”。

告警功能是各大云平台必不可少的模块，个性化的告警配置，为帮助用户和运维人员及时发现问题发挥着重要作用。 数据库智能监控系统（简称DMS）告警框架（以下简称告警框架）用于监控数据仓库的集群信息，且基于8.1.1以上版本的集群进行开发，如果您的集群版本低于8.1.1或没有安装DMS，则不能适用此告警功能。 告警功能是结合产品自身需求、业务需求、客户需求独立进行设计与开发，为了能够让用户更快速的熟悉和使用此功能，告警功能在设计之初也参照了其他平台的使用方式、相关概念，并结合自身情况进行调整，完成了初版的设计与开发。 在说具体实现之前，先了解下告警框架中涉及的相关概念。 告警指标：告警指标是实际监控的内容，如：CPU使用率、磁盘使用率、IO等。 告警策略：告警策略是触发告警的最小单元，每一条策略针对一种告警指标。告警策略分为阈值策略、状态策略等。 告警规则：告警规则是实际监测（任务调度）的最小单元，是告警策略的集合。告警规则包含自默认规则和自定义规则。 默认告警规则：默认规则是系统提供的基础告警项，用户只需根据业务简单的配置，即可收到告警信息。 自定义告警规则：当默认告警规则不能满足实际需求时，用户可根据自己的实际需求创建自定义告警规则。 规则、告警策略、告警指标三者关系：一个告警规则（默认/自定义）可包含多个告警策略，并且规则中的策略存在不同关系。

锁是GaussDB(DWS)实现并发管理的关键要素，GaussDB(DWS)锁类别有表级锁、分区级锁(和表级锁一致)、事务锁、咨询锁等，当前业务最常用的是表级锁、分区级锁(和表级锁一致)、事务锁。不同的SQL语句执行时需要申请并持有对应的锁，当这些锁资源存在互斥时，对应的业务SQL就会产生等待；这种等待会产生下面几种后果： 1、持锁的一方释放锁(一般对应的动作为持锁的事物提交)，等待锁的一方申请到锁，然后继续执行； 2、持锁的一方事物长时间未提交，等待锁的一方因为锁等待超时导致作业报错； 3、A实例上持锁事物和申请锁的事物在B实例上角色互换，产生分布式死锁(具体见下文介绍)。这种场景下需要首先达到锁等待超时的事物报错回滚时释放锁资源，然后另外一个事物申请到才能正常进行。 从上述的描述可以看到，锁等待特别是分布式死锁对业务影响很大，轻则产生等待导致业务性能抖动和下降，甚至业务报错。GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级问题的定位和分析。 对于分布式死锁，只能一个事务因为锁等待（参数lockwait_timeout）超时回滚的时候，另外一个事务才能进行下去；或者人工干预kill或者cancel其中一个事务，让另外一个事务进行下去。对于没有分布式死锁的锁等待，这种一般不需要人工干涉，等待持锁事务正常执行完成之后另外一个事务就可以正常执行；但是如果事务持锁时间超过锁等待超时参数（参数lockwait_timeout），等待锁的事务会因为锁等待超时失败。

游标是一种数据处理方法，提供了在查询结果集中进行逐行遍历浏览数据的方法，也可以将游标当做上下文区域的句柄或者指针，借助游标对指定位置的数据进行查询与处理。在存储过程的DECLARE中声明游标定义TYPE CURSOR_TYPE IS REF CURSOR;同时GaussDB(DWS)做了Oracle兼容，支持sys_refcursor动态游标类型，函数或存储过程可以通过sys_refcursor参数传入或传出游标结果集合，函数也可以通过返回sys_refcursor来返回游标结果集合。 在处理完游标的数据后，应及时释放游标，以便释放游标所占用系统资源，游标关闭后工作区将变成无效，不能再使用FETCH语句获取其中数据。关闭后的游标可以使用OPEN语句重新打开。 可以通过游标的属性来了解当前游标的状态。下面将介绍4中游标属性：%FOUND布尔型属性：当最近一次读记录时成功返回，则值为TRUE。%NOTFOUND布尔型属性：与%FOUND相反。  %ISOPEN布尔型属性：当游标已打开时返回TRUE。 %ROWCOUNT数值型属性：返回已从游标中读取的记录数。 对于非SELECT语句，例如UPDATE，DELETE操作，系统会自动的未这些操作设置游标，这些有系统隐含创建的游标即隐式游标。隐式游标的定义，打开，取值，关闭操作均有系统自动的完成，无需用户进行处理，用户只能通过隐式游标的相关属性完成相应的操作。

GaussDB(DWS)中的PLSQL语言，是一种可载入的过程语言，其创建的函数可以被用在任何可以使用内建函数的地方。例如，可以创建复杂条件的计算函数并且后面用它们来定义操作符或把它们用于索引表达式。SQL被大多数数据库用作查询语言。它是可移植的并且容易学习。但是每一个SQL语句必须由数据库服务器单独执行。这意味着客户端应用必须发送每一个查询到数据库服务器、等待它被处理、接收并处理结果、做一些计算，然后发送更多查询给服务器。如果客户端和数据库服务器不在同一台机器上，所有这些会引起进程间通信并且将带来网络负担。通过PLSQL语言，可以将一整块计算和一系列查询分组在数据库服务器内部，这样就有了一种过程语言的能力并且使SQL更易用，同时能节省的客户端/服务器通信开销。客户端和服务器之间的额外往返通信被消除，客户端不需要的中间结果不必被整理或者在服务器和客户端之间传送，多轮的查询解析可以被避免。在当前GaussDB(DWS)的能力中主要支持两种过程化SQL语言，即基于PostgreSQL的PL/pgSQL以及基于Oracle的PL/SQL。

对于服务可用性，主备从HA与三副本多数派复制和两副本最大可用HA相同，都能够容忍单副本故障。对于数据可靠性，主备从HA提供了强于两副本、接近三副本的能力。备机故障一段时间后恢复。从时间轴上看，可以分为P1主备同步、P2主从同步、P3备机追赶和P4主备同步四个阶段。 P1/P4：主备同步，数据拥有两副本可靠性，数据可靠性与传统两副本相同。 P2：发生单节点故障，主从同步，数据仍然具有两副本可靠性，优于传统两副本。此时如果主机磁盘损坏无法恢复，由于从备仍有一份数据，当备机恢复后即可提供服务，而传统两副本则必须等待主机恢复才能提供服务，否则会数据丢失。 P3：备机恢复后追赶P2阶段生成的日志和数据，此时主机仍然与从备强同步并正常服务。追赶阶段一旦发生主机故障，备机升主时可以连接从备补齐日志和数据并提供服务；而传统两副本则因备机没有追赶完成而无法恢复服务，否则会数据丢失。 以上，主备从HA在P2、P3阶段相比两副本有额外的可靠性优势。而相比三副本，只有在主备两节点都发生磁盘损坏且不可恢复的场景下，可靠性方面具有劣势。

尽管GaussDB for DWS主备间是强同步，但各自落盘顺序总有先后。与绝大多数数据库一样，GaussDB for DWS的物理日志总是先写主机后写备机。如上图所示，主机崩溃前可能有一部分日志未同步给备机（红色部分未同步，蓝色部分已同步），备机升主后会提供服务，会写入新的日志（绿色部分）。由于物理日志按照lsn顺序递增，主机的红色日志与备机的绿色日志占用了相同的一段lsn，形成冲突，即日志分叉。 日志分叉可能带来严重问题，例如一旦分叉后发生集群重启，传统两副本方式可能无法通过日志长度判断应该选谁成为新主，选错将造成数据丢失（应选包含绿色日志的节点为主，因为其可能包含已提交事务；而红色段日志一定不存在已提交事务，可以丢弃）。 在引入从备后，主机故障备机升主，升主后将与从备进行强同步，因此从备上的日志一定与新主保持一致。在上述场景中，DN响应升主命令时可以额外判断从备日志，通过校验CRC来判断日志是否分叉，与从备日志一致的才能升主成功，从而保证了仲裁的正确性和数据的一致性。 此外，在极限断网、进程僵死、集群管理失效等场景下，有可能在主机存活时错误的将备机升主，形成双主脑裂。传统的两副本HA机制无法识别此类场景，只能通过外部加固手段减少脑裂发生的概率。而在主备从架构下，从备可临时作为仲裁者，类似三副本多数派机制。DN响应升主时与从备建连并进行日志校验，只有与从备形成多数派的主机才实际有效，而另外的主机因无法与从备强同步而自动失效，从而解决了脑裂的问题。

随着客户业务对数据可靠性和服务可用性要求的提高，主备架构在OLAP系统中也已被广泛使用。而分析型数据库往往数据量大，节点数多，分布式系统下发生硬件故障已成为常态。 对于传统两副本系统（一主一备最大可用HA模式），单节点故障后，为了服务可用性，一般都会选择让另一个正常节点继续提供服务，在故障节点恢复前数据只有单副本运行。而由于数据量大，往往故障节点修复时间和数据重建时间都很长，此时一旦正常主机再次发生故障，将造成数据丢失的严重后果。另外，根据分布式CAP原理，两副本系统一旦采用最大可用策略，将损失分区容错性（即脑裂双主，下文详述）。 尽管三副本通过多数派复制策略可以解决上述问题，但三副本带来了更多的存储成本开销，在OLAP数据库中无法成为主流解决方案。因此，GaussDB for DWS创新性的在数据节点（DN）引入从备概念，使得集群在任意单点故障时仍保持两副本可用，相比传统三副本节约了三分之一的存储空间，但数据可靠性基本持平。 GaussDB for DWS引入备机和从备的概念，正常情况下主机和备机通过日志流复制和数据页流复制进行强同步，主机与从备仅保持连接并不发送日志和数据，因此从备不占用额外存储资源。当备机发生故障时，主机自动感知，将未完成同步的日志和数据发送给从备，并保持主从强同步。主备同步向主从同步的切换在内核底层HA实现，事务层并不感知，因此不会造成任何报错和不一致。 同理，当主机发生故障时，由集群管理感知并仲裁备机升主，升主后的备机连接从备进行主从强同步。因此，在一组DN内发生单点故障后，不会影响服务可用性，同时数据仍然有两份副本的可靠性保障。

实例级别内存管控：guc参数max_process_memory限制DN和CN实例的最大可用内存，当使用内存超过max_process_memory时，作业报错退出； 可动态申请内存：max_dynamic_memory=max_process_memory-cstore_buffers(max_cstore_memory)-(udf_memory_limit - 200M) - max_shared_memory； 资源池内存管控：使用并发点数计算可执行的并发数量，active_statements<=0情况下资源池内存不受控。资源池总点数：total_points = active_statements * 100，作业使用点数：active_points = (estimate_mem/respool_mem) * active_statements * 100，estimate_mem为优化器估算的作业内存，资源池点数耗尽出发排队。