WDR是GaussDB(DWS)数据库监控特性的衍生品。数据库内核在运行过程中积累了大量的一手数据，像执行各类SQL的数量，表和索引的访问次数和时间，CPU、内存等底层软硬件的运行情况等。用户可以通过数据库提供的系统视图实时查询这些数据。例如，查询PGXC_WORKLOAD_SQL_COUNT视图可以获得自数据库启动以来各类SQL的执行次数。将这些一手的性能监测数据保存下来，并进行自动化的统计分析，就得获知某段时间内数据库的运行情况，例如是否繁忙，是否有不合理的SQL，有哪些异常事件等，从而为诊断问题，性能调优提供参考依据。这便是WDR的由来。对监测数据进行分析之前先要保存下来。出于性能考虑，数据库内核将各种监测数据都放在了内存里，以便快速更新和读取。一旦进程重启，这些数据将会丢失。因此，WDR做的第一件事就是将内存里的检测数据保存到外设上。这些被保存的性能监测数据被称为“快照”，而保存的过程称为“创建快照”。注意不要将这里的“快照”与数据库的Snapshot混淆。后者指的是Database中的数据在某一时刻的状态，而WDR创建的“快照”是指将某一时刻查询到的系统视图的内容保存在专门的表格中。

1、创建组用户关联组资源池CREATE USER tenant_a RESOURCE POOL 'resource_pool_a' PASSWORD 'Gauss_234';2、创建业务用户关联业务资源池CREATE USER tenant_a1 RESOURCE POOL 'resource_pool_a1' USER GROUP 'tenant_a' PASSWORD 'Gauss_234';3、通过设置用户属性（PERM SPACE、TEMP SPACE、SPILL SPACE）可以进行存储空间管控：（1）修改用户“tenant_space_test”永久表空间限额不受限制。ALTER USER tenant_space_test PERM SPACE 'unlimited';（2）修改用户“tenant_space_test”临时表空间限额为100G。ALTER USER tenant_space_test TEMP SPACE '100G';（3）修改用户“tenant_space_test”算子落盘空间限额为200G。ALTER USER tenant_space_test SPILL SPACE '200G';

通过设置资源池属性可以进行以下几方面的资源隔离：（1）通过设置mem_percent、memory_limit进行内存资源管理；（2）通过设置io_limits、io_priority进行IO管控；（3）通过设置active_statements、max_dop进行并发管控；（4）可以设置指定的控制组，进行CPU和异常规则的管理；（5）设置资源池异常规则；1、组资源池创建名称为“resource_pool_a”的组资源池关联到了“class_a”控制组。CREATE RESOURCE POOL resource_pool_a WITH (control_group='class_a');2、业务资源池（1）创建名称为“resource_pool_a1”的业务资源池关联到了“workload_a1”控制组CREATE RESOURCE POOL resource_pool_a1 WITH (control_group='class_a:workload_a1');（2）更新一个资源池，其控制组指定为"DefaultClass"组下属的"High" Timeshare Workload控制组。ALTER RESOURCE POOL pool1 WITH (CONTROL_GROUP="High");（3）修改资源池“resource_pool_a1”的内存比例为可用内存大小的20%，即设置MEM_PERCEN的取值为20。ALTER RESOURCE POOL resource_pool_a1 WITH (MEM_PERCENT=20);

多租户为满足客户混合负载处理需求而生，通过提供两层用户机制，分层资源隔离，满足客户对计算和存储资源的自主控制需求。两级用户分别关联不同的资源池和存储空间，实现多租户下资源分组管理。目前GaussDB(DWS)的多租户能够进行隔离的资源包括：CPU资源、内存资源、IO资源、存储资源。通过设置控制组可以进行以下几方面的资源隔离：（1）设置CPU核数和控制组CPU份额，进行CPU资源管理；（2）设置异常规则来对异常作业进行终止或降级；1、class控制组创建名称为“class_a”的子Class控制组，CPU资源配额分别为Class的40%。gs_cgroup -c -S class_a -s 402、workload控制组创建子Class控制组“class_a”下名称为“workload_a1”的Workload控制组，CPU资源配额分别为“class_a”控制组的20%。gs_cgroup -c -S class_a -G workload_a1 -g 203、异常规则设置“class_a”下属“workload_a1”的作业阻塞到1200秒或执行2400秒时执行终止动作。gs_cgroup -S class_a -G workload_a1 -E "blocktime=1200,elapsedtime=2400" -a

1.移除死亡元组并对满足条件的老元组执行frozen操作。2.移除指向死亡元组的索引元组，更新对应表的fsm 和 vm 文件FSM: free space map 空闲空间映射文件，插入数据时会根据该文件来选择合适的page.VM: visibility map 可见性映射文件，后续vacuum时会根据该文件来选择是否扫描某个page,提高vacuum效率；同时在进行index-only-scan时也会使用该文件来提高可见性判断的效率）。3.更新统计数据pg_stat_all_tables。Linepointer 不会被移除，用于在之后复用。Oldestxmin的推进vacuum 只能清理掉当前全局存活的最老事务(OldestXmin)之前的事务所产生的垃圾数据，所以如果仍然存在老事务的话（比如长事务或者长sql的存在）,新事务所产生的垃圾数据并不会被vacuum立即清理。元组被删除后，只有当vacuum将元组的LinePointer(或者叫item pointer, 指向具体的元组)置为LP_UNUSED状态后，该LinePointer才有可能在新插入数据时复用。4.Fsm还未生成插入数据时，依赖fsm文件来选择可用的page，如果fsm没有生成则会导致使用新的page而不是复用旧的。5.批量导入在旧版本GaussDB(DWS)中，对表进行批量插入数据的操作时，会直接申请新的page来插入数据。所以在某些场景下虽然vacuum后清理了脏数据，但由于业务场景以批量插入为主，导致vacuum对膨胀的控制效果并不理想。目前已经支持批量插入数据时对空间的复用。

FSM查找和维护的逻辑并不复杂，但是整个过程对外是不可见的。因此GaussDB(DWS)提供了pagehack工具来读取FSM文件，帮助查看当前数据页的空闲空间情况。下面结合pagehack工具解析FSM文件进一步理解FSM机制：初始化数据首先新建行存表并插入大量数据。分布列数据固定，为了让数据都落入一个dn，方便后面分析。删掉 2 条位于第一个heap page的数据。因为是新建的表，所以数据会从前往后顺序的落到数据页面里，c2等于1和2的两条数据一定在第一个页面上。接着看到第二个fsm block，属于level medium，记录的最大空闲空间为31，数组0位置代表下层的fsm block 0有2个slot，数组108位置代表fsm block 108 有31个slot，其他都是0。0~108中间的0表示没有这些页面都没有空闲空间了，108之后的表示页面还没有扩展出来。再往后面是第三个fsm block，这个及以后的block都属于level bottom，这层的FSM页面都是直接对应数据页面的。可以看到最大剩余空间为2，数组0位置代表heap page 0 有2个位置，正好是刚才删除的两条数据。第4个及后面的一直到110的block的信息如下，可以看到整个heap page都没有剩余空间了，这是因为这些页面一直在插入，没有删除数据。

为了解决无效元组占用空间的问题，GaussDB(DWS)提供了vacuum功能，在旧版本元组过期（对所有事务都不可见）后，vacuum可以将元组物理删除，这样页面上被清理出来的空闲空间就可以被再次使用了。但是每个页面的空闲空间又不是固定大小的，所以如果要利用这些空间空间，就需要遍历一遍数据页面来找到它们，但是这样会造成比较大的开销。因此就设计了用来记录每个页面剩余空间的空闲空间映射表FSM（Free Space Mapping），以便高效的将空闲空间管理起来，方便查找和重新使用。FSM是以 _fsm 为后缀的文件对外展现的，每个行存表都有一个fsm文件。在表创建时，fsm文件并不会一起创建出来，而是在第一次vacuum时才会被创建。因为不同页面上的元组长度各不相同，为了快速高效的管理空闲空间，没必要非常精确的管理每一个字节。将一个8K的数据页面（data block）分成256份，从页面头到页面尾顺序计算，排除页面头等固定支出，最多可以有255份空闲空间，这样FSM用1个Byte就可以标识出一个数据页面的空闲空间的大小。在空闲空间查询时，我们只需要找到能满足需求的页面即可，所以FSM将每个页的空余空间信息通过一个大根堆结构进行维护。这样只需要从堆的根获取当前最大的剩余空间就可以知道有没有能符合要求的页面。堆中的每个叶子节点都对应一个数据页，叶子节点上记录的是数据页的可用单元的个数。然后FSM机制通过在不同的FSM页间维护了一个类似FSM本身的树形结构，来管理所有的FSM block：一个3层的多叉树结构。FSM页面也是大小为8K的块（FSM block），所以每个FSM block最多可以描述4096个数据页面。按照3层计算：4096（0层）4096（1层）（8k*4096）（2层） = 2PB。可以管理2PB的数据，这对描述一张行存表，完全够用了。

数据膨胀，指的是物理数据文件的大小明显高于实际存储的数据量。 甚至某些特殊场景下，一个表中只有一条简单的数据，但是表对应的物理文件可能已经达到M级甚至G级。为了解决数据膨胀，GaussDB(DWS)通过vacuum和FSM来清理和重用物理空间。 本文简单介绍FSM的设计和原理，并通过一个例子对FSM功能进行简单的测试和验证。数据膨胀的原因想弄清楚数据膨胀的原因，首先要了解GaussDB(DWS)行存表数据基于MVCC的存储机制：INSERT很简单，就是将元组插入到页面的空闲空间中；DELETE则是将元组标记为旧版本，但是即使这个旧版本对所有事务都不可见了，这个元组占用的空间也不会归还给文件系统；UPDATE相当于DELETE+INSERT，等于是占用了两条元组的位置，类似DELETE，旧版本的元组依然占用着物理空间。很明显，在一通增删改操作之后，页面上的旧版本元组势必是占有一定比重的。这就导致了物理文件大小明显高于实际的数据量。

1. frame目录存放 SyncDataToStby.py 生成的log，涉及到双集群调度，备份集清理，状态显示，配置文件及命令行参数解析的功能。2. controller目录存放 GaussRoach.py 生成的log，涉及到备份、恢复准备工作一些操作，备份、恢复参数解析，备份集群的处理，错误处理等3. agent目录存放 gs_roach工具 生成的log，涉及到gs_roach 连接gaussdb/gtm/cm发起备份/恢复，生成备份集/恢复备份集等操作。gs_roach工具功能：在备份侧完成将cn/dn/gtm/cm的数据文件按顺序打包成备份文件的功能，并生成备份集元信息文件; 恢复侧根据元信息文件将备份集文件解压到对应cn/dn/gtm/cm的数据目录中。定位步骤1. 确定问题在备份侧还是恢复侧，查找双集群主结点上Sync日志，确定出错的模块2. 确定出错的层次，由于双集群执行过程是一个上下层调用及时序关系的方式，具体顺序参考：crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach3. 在各个模块都有较详细的日志描述过程，具体问题具体分析，大体有如下几个方面1）配置出错，用户、环境变量文件2）备份集群路径权限问题3）由于集群状态非Normal导致备份失败4）结点故障及备份集损坏导致恢复失败

GaussDB(DWS)的容灾方案是一个双集群同步的架构，即两套独立集群定期同步数据以达到容灾的目的。目前数据同步的方式是通过roach(GaussDB(DWS)备份、恢复工具)定期做增量备份和恢复同步。双集群框架是一个复杂的分布式系统，在出现问题时，如何快速准确的定位问题及恢复服务是一个非常紧迫的问题，这个问题在云上会更突出。本文通过介绍双集群的架构、log结构、分析步骤来介绍双集群容灾的问题分析方法。主备集群都是3c3d, 主集群的主结点部署双集群框架脚本，定期进行备份操作，备集群的主结点定期恢复备份集。基础数据需要进行一全量备份，之后增量备份。备份侧调用关系：SyncDataToStby.py -> GaussRoach.py -> gs_roach恢复侧调用关系：SyncDataToStby.py -> GaussRoach.py -> gs_roach了解调用关系和咱们分析问题有直接的关系。SyncDataToStby.py 是整个双集群的调用起始，控制着双集群的正常运行，正常情况下是长驻内存的进程，如果异常退出后，后台会有crontab的来重新拉起双集群脚本: crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach

当前支持从集群级全量备份集、或schema级别备份集中做多表细粒度恢复，这两种主要场景核心技术思想一致，场景支持情况如下：支持单次从集群级全量备份集中恢复单表或多表，恢复表的名称列表写入一个配置文件，配置文件名由恢复参数—table-list指定；集群级全量备份集恢复单/多表，指定待恢复的表可跨多个schema；恢复时可指定恢复到原表或新表，新表可与原表在不同schema，但需要在同一个database，表名可为新表名；指定的恢复目标schema可以存在，也可以不存在，恢复时新建出来，恢复的新表由—restore-target-list指定的文件配置，若希望全部恢复到原表名，则—table-list和—restore-target-list可指定同一配置文件；若恢复时指定的恢复目标表存在（原表名或新表名），那么恢复可指定—clean参数先drop cascade级联删除该表（视图、索引、权限等一并删除）再恢复，不带该参数，则需要用户手动确认后drop，再进行恢复，这主要是为了应对备份和恢复时前表名相同，但表定义不同的场景。细粒度是在线恢复，不清理数据也不停集群，恢复完成后表可直接使用，无build等额外时间消耗。

如题，我需要在windows 7 的本地机器上执行外表插入操作，并将数据落地到本地文件夹下，请问是否有windows 7 版本的 gds , 谢谢

我的程序需要在win7 环境下运行，同时也要在linux环境运行。 现在linux上的程序是使用了 gsql 链接数据库，请问如果在win7 上运行 应该如何获取 对应的gsql 客户端？

针对规模比较大集群如何快速查单表或单schema的脏页率？针对规模比较大集群如何快速查分区表的分区脏页率？

gaussdb中有insert并发的方式吗？有类似oracle中enable_parallel_dml的参数或方式吗？