From ea762f65ec26e095a0b4dd09538421908a6a5af7 Mon Sep 17 00:00:00 2001
From: root <1603812043@qq.com>
Date: Mon, 23 Dec 2024 21:42:09 +0800
Subject: [PATCH] =?UTF-8?q?=E9=85=8D=E7=BD=AE=E4=BE=9D=E8=B5=96=E6=A3=80?=
 =?UTF-8?q?=E6=9F=A5=E9=A1=B9=E8=AF=B4=E6=98=8E=E6=8F=90=E4=BA=A4?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...15\347\275\256\345\237\272\347\272\277.md" | 1537 ++++++++++++++++-
 1 file changed, 1523 insertions(+), 14 deletions(-)

diff --git "a/secure-configuration-benchmark/release/openGauss\345\256\211\345\205\250\351\205\215\347\275\256\345\237\272\347\272\277.md" "b/secure-configuration-benchmark/release/openGauss\345\256\211\345\205\250\351\205\215\347\275\256\345\237\272\347\272\277.md"
index 570dbf4..a759a95 100644
--- "a/secure-configuration-benchmark/release/openGauss\345\256\211\345\205\250\351\205\215\347\275\256\345\237\272\347\272\277.md"
+++ "b/secure-configuration-benchmark/release/openGauss\345\256\211\345\205\250\351\205\215\347\275\256\345\237\272\347\272\277.md"
@@ -647,6 +647,259 @@ gs_om -t stop && gs_om -t start
 **参考来源：**
 无
 
+### OPENGAUSS.O_6.G_1.R_15：为超级用户预留连接数不能为0
+
+**配置组ID:**
+OPENGAUSS.G_1
+
+**配置组名称:**
+连接配置
+
+**规则ID:**
+OPENGAUSS.O_6.G_1.R_15
+
+**规则名称:**
+为超级用户预留连接
+
+**级别:**
+要求
+
+**规则背景说明:**
+
+在进行数据库操作时需要能够正常连接数据库,如果没有为超级用户预留连接,可能会出现以下几种情况和问题：
+* 管理操作受限
+* 数据库性能监控和调优困难
+* 无法处理紧急情况,恢复操作困难
+* 安全管理问题
+
+**影响：**
+
+无
+
+**检查方法：**
+```sql
+select setting from pg_settings where name = 'sysadmin_reserved_connections'
+```
+检查结果是否为0
+
+**修复方法：**
+
+```bash
+gs_guc set -Z datanode -N all -I all -c "sysadmin_reserved_connections=%s"
+gs_om -t stop && gs_om -t start
+```
+* 配置调整：确保数据库配置文件中为超级用户预留了足够的连接。例如，在OpenGauss中，可以通过调整配置文件中的参数来确保超级用户能够连接数据库。
+
+* 监控连接数：定期监控数据库的连接使用情况，确保超级用户能够在需要时获得连接。如果连接数接近或超过限制，考虑增加连接数配置或优化连接管理策略。
+
+* 用户管理：定期检查数据库用户的权限和角色，确保只有必要的用户占用连接资源，同时为超级用户分配合适的权限和连接资源。
+
+* 测试和验证：定期进行测试和验证，确保在不同场景下超级用户能够顺利连接数据库，并能够执行其管理任务。
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_1.R_16：当前连接数不能超过最大连接数的70%
+
+**配置组ID:**
+OPENGAUSS.G_1
+
+**配置组名称:**
+连接配置
+
+**规则ID:**
+OPENGAUSS.O_6.G_1.R_16
+
+**规则名称:**
+OpenGauss数据库的当前连接数不能超过最大连接数的70%
+
+**级别:**
+要求
+
+**规则背景说明:**
+
+当OpenGauss数据库的当前连接数超过最大连接数的70%，可能会遇到以下问题：
+
+* 连接请求失败：新连接请求可能会因为没有可用的连接池而被拒绝，导致应用程序或用户无法连接到数据库。
+
+* 性能下降：高连接数可能导致系统资源紧张，如内存和CPU使用率增加，可能影响数据库的性能和响应时间。
+
+* 锁争用增加：大量连接可能导致锁争用增多，从而影响事务的并发性能和整体事务处理速度。
+
+* 维护和管理困难：过高的连接数可能使得数据库的管理和维护变得更加复杂，可能影响监控、备份、恢复等操作的效率。
+
+**影响：**
+1. 连接请求被拒绝
+* 当前连接数接近或超过最大连接数时，新发起的连接请求将无法被数据库接受。openGauss 会拒绝超过最大连接数限制的连接请求，这样应用程序就无法建立新的连接，可能导致服务中断或者响应延迟。
+
+* 影响应用程序：当数据库无法接受新连接时，任何尝试建立连接的应用都会失败，可能导致用户请求无法处理或业务无法正常运行。
+2. 性能下降
+   在接近最大连接数的情况下，数据库可能会面临以下性能问题：
+
+* 资源竞争：每个连接都需要一定的系统资源（如内存和CPU时间）。当连接数接近最大限制时，系统资源可能会趋于紧张，导致响应时间变长，甚至出现查询延迟。
+* 上下文切换开销：更多的连接意味着数据库需要频繁进行上下文切换，管理多个连接的会话，这也会增加CPU和内存负载，导致系统性能下降。
+3. 内存和资源压力
+* openGauss 会为每个连接分配一定的内存和系统资源。如果连接数接近最大值，这些资源可能会耗尽，从而导致数据库系统的稳定性受到威胁。特别是在高并发场景下，资源可能会迅速消耗，影响到数据库的响应和处理能力。
+
+4. 事务处理和并发能力受限
+* 事务处理能力下降：随着连接数的增加，数据库可能需要处理更多的并发事务。如果最大连接数限制得比较紧，数据库的并发处理能力可能受到限制，从而导致事务排队等待，增加延迟。
+* 锁竞争：更多的连接可能导致锁竞争加剧，特别是对于高并发场景，可能会影响事务的并发性和效率。
+
+**检查方法：**
+
+current_connections
+```sql
+select count(1) from pg_stat_activity;
+```
+max_connections
+```sql
+show max_connections;
+```
+current_connections_percent = current_connections * 100 / max_connections
+
+
+**修复方法：**
+
+```bash
+gs_guc set -Z datanode -N all -I all -c "max_connections=%s"
+gs_om -t stop && gs_om -t start
+```
+
+* 调整最大连接数：考虑增加max_connections参数的值，以便支持更多的连接请求。
+
+* 优化连接使用：审查和优化应用程序的连接使用模式，如使用连接池来减少连接数。
+
+* 资源监控：监控数据库资源的使用情况，确保系统能够处理当前的负载，并在必要时进行扩展或调整配置。
+
+* 负载均衡：在负载较高的情况下，考虑使用负载均衡策略来分配连接负载。
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_1.R_17：为超级用户预留连接不能超过最大连接的20%
+
+**配置组ID:**
+OPENGAUSS.G_1
+
+**配置组名称:**
+连接配置
+
+**规则ID:**
+OPENGAUSS.O_6.G_1.R_17
+
+**规则名称:**
+为超级用户预留连接不能超过最大连接的20%
+
+**级别:**
+要求
+
+**规则背景说明:**
+
+如果为超级用户预留的连接数超过了最大连接数的20%，可能会引发以下问题：
+
+* 普通用户连接受限：超级用户占用较多的连接资源，可能会导致普通用户的连接请求被拒绝，从而影响应用程序和用户的正常操作。
+
+* 资源分配不均：预留的连接数过高可能导致资源分配不均，影响整体系统性能，特别是在连接资源紧张时。
+
+* 管理操作受到影响：如果超级用户连接数过高而普通用户连接数不足，可能会影响数据库的日常管理和维护操作，如性能调优、备份和恢复。
+
+**影响：**
+1. 超级用户连接数受限
+* 超级用户连接数最多只能占用总连接数的20%。举个例子，如果数据库总连接数为100个，那么超级用户最多只能使用20个连接。
+* 这种限制会导致在高并发的情况下，超级用户无法获得足够的连接数进行数据库管理和维护任务。如果数据库负载过高，超级用户可能无法执行必要的管理操作，如备份、恢复等。
+2. 普通用户的连接优先保障
+* 超过20%的连接数将不再分配给超级用户，这意味着普通用户的连接会优先得到保障，避免超级用户过度占用连接资源，从而影响到普通用户的正常使用。
+* 对于高并发的生产环境，这种设计有助于确保普通用户在数据库负载较高时，仍然能够正常进行数据库操作，不会因为超级用户的连接需求过多而导致业务中断或响应缓慢。
+3. 数据库性能和资源保护
+* 限制超级用户的连接数能够有效保护数据库资源，确保普通用户的连接不会被超级用户占用过多。这对于数据库的稳定性至关重要，尤其是在高负载的环境中，能够避免因为超级用户占用过多连接而导致普通用户请求阻塞，从而提升系统的可用性和响应速度。
+* 超级用户的连接数限制可以作为一种性能调优手段，避免由于管理操作造成的资源浪费或系统性能下降。
+
+
+**检查方法：**
+
+super_connections执行sql获得
+```sql
+select setting from pg_settings where name = 'sysadmin_reserved_connections'
+```
+max_connections执行sql获得
+```sql
+show max_connections;
+```
+superuser_reserved_connections_ratio = superuser_reserved_connections * 100 / max_connections
+
+
+**修复方法：**
+```bash
+gs_guc set -Z datanode -N all -I all -c "superuser_reserved_connections=%s"
+gs_om -t stop && gs_om -t start
+```
+* 优化预留连接配置：确保超级用户的预留连接数在合理范围内，通常建议将其设置为最大连接数的5%-10%。
+
+* 调整最大连接数：如果需要更多的连接资源，可以考虑增加数据库的最大连接数配置。
+
+* 监控和调整：定期监控数据库连接使用情况，并根据实际需要调整预留连接和最大连接数的设置。
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_1.R_18：平均连接时间应大于10min
+
+**配置组ID:**
+OPENGAUSS.G_1
+
+**配置组名称:**
+连接配置
+
+**规则ID:**
+OPENGAUSS.O_6.G_1.R_18
+
+**规则名称:**
+平均连接时间<10min,建议使用连接池
+
+**级别:**
+要求
+
+**规则背景说明:**
+
+平均连接时间小于10分钟,这可能意味着数据库性能优化出现了问题,一个较短的连接时间可能表明数据库无法有效地处理连接请求，或者存在网络或服务器性能方面的问题。在实际应用中，这可能导致用户体验不佳、系统稳定性下降以及对关键业务功能的影响
+
+**影响：**
+1. 用户体验下降
+* 延迟感知：用户在连接数据库时可能会感到明显的延迟，尤其是对于需要频繁连接和断开连接的应用（如Web应用、微服务架构等），这种延迟会直接影响用户体验。
+* 不响应问题：连接时间过长可能导致应用程序在等待数据库响应时变得不敏感，用户可能会认为应用程序卡顿或无响应。
+2. 应用程序性能下降
+* 高并发压力：如果多个应用程序实例或多个用户频繁连接数据库，较长的连接时间会导致连接池中连接数增加，从而增加数据库负载。尤其在高并发环境下，连接建立的延迟会变得更加明显。
+* 连接池资源浪费：长时间的连接建立过程会导致连接池中的连接资源被长时间占用，从而减少可用连接数，增加排队等待的概率。
+3. 资源消耗
+* 数据库端资源占用：每一个连接都需要数据库端维护一些状态信息和资源。较长的连接时间可能导致连接数过多，从而消耗大量的数据库资源（如内存、CPU等）。
+* 网络带宽占用：如果连接时间长，网络带宽可能被不必要的连接占用，从而影响到其他服务或数据流的稳定性和性能。
+4. 系统不稳定性
+* 连接池溢出：当连接池中的连接被长时间占用，新的连接请求可能会被拒绝或延迟，这会导致应用程序性能下降，甚至出现系统崩溃。
+* 超时和错误：较长的连接时间可能引发超时错误，尤其是在使用有严格超时限制的应用程序中，导致连接失败和错误频发。
+
+
+**检查方法：**
+
+```sql
+select extract(epoch from avg(now()-backend_start)) as age from pg_stat_activity;
+```
+判断结果是否小于10分钟
+
+**修复方法：**
+* 配置连接池：使用连接池可以有效管理数据库连接，减少频繁创建和销毁连接的开销，提高连接利用率。可以配置连接池参数，如最大连接数、最小连接数等，以适应实际负载需求。
+
+* 优化查询性能：分析和优化数据库查询，使用适当的索引和执行计划，减少查询时间，降低对连接的等待时间。
+
+* 监控和调整系统资源：监控数据库的资源使用情况（如CPU、内存、IO），确保系统配置符合负载需求。根据实际情况调整服务器硬件配置和数据库参数。
+
+* 检查网络延迟：确认网络延迟和稳定性问题，确保数据库和应用程序之间的网络连接正常。
+
+* 调优数据库配置：调整数据库的配置参数，如连接超时、并发连接数等，以提高整体性能和稳定性。
+
+**参考来源：**
+无
+
+
 ## 文件目录安全
 
 ### OPENGAUSS.O_6.G_2.R_1：确保数据库安装目录权限最小化
@@ -2440,29 +2693,29 @@ OPENGAUSS.O_6.G_6.R_6
 
 **规则背景说明：**
 
-参数`audit_system_object`决定是否对数据库对象的CREATE、DROP、ALTER操作记录审计日志。这些数据库对象包括DATABASE、USER、SCHEMA、TABLE等。该参数的值由28个二进制位的组合求出，这28个二进制位分别代表openGauss的26类数据库对象（包含两个保留位）。如果对应的二进制位取值为0，表示不审计对应的数据库对象的CREATE、DROP、ALTER操作；取值为1，表示审计对应的数据库对象的CREATE、DROP、ALTER操作。这26个二进制位代表的具体审计内容请参见openGauss的官方文档中对`audit_system_object`参数的说明。
+参数`audit_system_object`决定是否对数据库对象的CREATE、DROP、ALTER操作记录审计日志。这些数据库对象包括DATABASE、USER、SCHEMA、TABLE等。该参数的值由20个二进制位的组合求出，每个二进制位代表openGauss Kernel中的一类数据库对象。如果某个二进制位取值为0，则不审计对应数据库对象的CREATE、DROP、ALTER操作；如果取值为1，则审计这些操作。具体每个二进制位代表的审计对象请参考openGauss的官方文档中对`audit_system_object`参数的说明。
 
 **影响：**
 无
 
 **检查方法：**
 
-检查`audit_system_object`参数值配置，如果参数值小于默认值67121159则失败。
+检查`audit_system_object`参数值配置，如果参数值小于默认值12295则失败。
 
 ```sql
 openGauss=# show audit_system_object;
  audit_system_object
 ---------------------
-67121159
+ 12295
 (1 row)
 ```
 
 **修复方法：**
 
-参数`audit_system_object`参数值设置为67121159，表示只对DATABASE、SCHEMA、USER、DATA SOURCE、SQL PATCH这五类数据库对象的CREATE、ALTER、DROP操作进行审计。用户可根据业务需要开启对更多数据库对象DDL操作的审计。
+参数`audit_system_object`参数值设置为12295，表示对DATABASE、SCHEMA、USER、DATA SOURCE、NODE GROUP等数据库对象的DDL操作的审计。用户可根据业务需要开启对更多数据库对象DDL操作的审计。
 
 ```bash
-gs_guc reload -Z datanode -N all -I all -c "audit_system_object = 67121159"
+gs_guc reload -Z datanode -N all -I all -c "audit_system_object = 12295"
 ```
 
 **参考来源：**
@@ -2758,13 +3011,13 @@ OPENGAUSS.O_6.G_6.R_12
 
 **检查方法：**
 
-检查`audit_file_remain_threshold`参数值配置，通常建议配置为默认值1048576。
+检查`audit_file_remain_threshold`参数值配置，通常建议配置为默认值1024。
 
 ```sql
 openGauss=# show audit_file_remain_threshold;
  audit_file_remain_threshold
 -----------------------------
- 1048576
+ 1024
 (1 row)
 ```
 
@@ -3584,6 +3837,139 @@ gs_guc reload -Z datanode -N all -I all -c "debug_print_rewritten=off"
 **参考来源：**
 无
 
+### OPENGAUSS.O_6.G_7.R_17：确保log_hostname==off
+
+**配置组ID：**
+OPENGAUSS.G_7
+
+**配置组名称：**
+错误报告和日志配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_7.R_17
+
+**规则名称：**
+确保log_hostname==off
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+当log_hostname设置为on时，除了记录客户端的IP地址外，还会尝试通过DNS解析来获取并记录客户端的主机名。这一设置在某些情况下可能会导致一些问题，主要包括以下几个方面：
+
+性能开销：解析主机名需要额外的时间和资源，这可能会带来一定的性能开销。特别是在高并发连接的情况下，这种开销可能会更加明显。
+
+DNS配置问题：如果DNS服务器配置不正确或存在网络延迟，可能会导致主机名解析失败或解析时间过长，进而影响数据库的响应速度。
+
+日志可读性：虽然记录主机名可以增加日志的可读性和易用性，但在某些情况下，如主机名频繁变化或DNS解析错误时，可能会导致日志中的主机名信息不准确或混乱。
+
+隐私和安全：在某些敏感环境中，记录客户端的主机名可能涉及隐私和安全问题。例如，如果主机名包含了敏感信息（如用户名或组织名称），那么这些信息可能会被泄露到日志文件中。
+
+综上所述，为了避免上述问题，通常建议将log_hostname设置为off，这样连接日志中只记录IP地址而不记录主机名。这样做可以减少性能开销、避免DNS配置问题、提高日志的准确性和安全性。
+
+**影响：**
+1. 性能影响
+* DNS 解析开销：当数据库在写日志时需要解析客户端的主机名，这会增加 DNS 查询的负担，尤其是在客户端数量较多或网络延迟较高的情况下。每次连接请求都需要通过 DNS 进行主机名解析，这可能会导致一定的性能下降。
+* 增加日志写入延迟：由于每次客户端连接都要进行主机名解析和记录，可能会增加数据库日志写入的延迟，尤其在高并发环境下尤为明显。
+2. 潜在的安全问题
+* 泄露客户端信息：如果数据库的日志包含了客户端的主机名，可能会泄露内部网络的结构或客户端的某些信息。这对于攻击者而言，可能会提供有关网络架构或客户端身份的信息，增加潜在的攻击面。
+* 难以区分合法与恶意客户端：在一些安全敏感的环境中，记录主机名可能会使恶意客户端伪装成合法客户端，从而使安全监控变得更加困难。
+3. 网络配置问题
+* DNS 解析失败：如果某些客户端的主机名无法通过 DNS 正常解析（比如 DNS 服务器配置错误或者网络中存在私有 IP 地址没有正确的 DNS 解析），则日志中可能无法记录有效的主机名，甚至会出现错误信息，影响日志的可用性和准确性。
+4. 日志管理复杂性
+* 增加日志大小：每次记录客户端的主机名都会增加日志条目的大小，尤其在大规模系统中，日志的体积可能会大大增加，增加了日志存储、传输和分析的复杂度。
+* 难以筛选和审计：在高流量环境下，记录大量主机名可能使得日志变得更加冗长，影响日志的筛选和审计效率，增加管理和监控成本。
+
+**检查方法：**
+
+检查`log_hostname`参数值是否为`off`，如果不为`off`则失败。
+
+```sql
+openGauss=# show log_hostname;
+log_hostname
+----------------------
+off
+(1 row)
+```
+
+**修复方法：**
+
+将`log_hostname`参数设置为`off`。
+
+```bash
+gs_guc reload -Z datanode -N all -I all -c "log_hostname=off"
+gs_om -t stop && gs_om -t start
+```
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_7.R_18：log_min_duration_statement不能为-1或者小于1000
+
+**配置组ID：**
+OPENGAUSS.G_7
+
+**配置组名称：**
+错误报告和日志配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_7.R_18
+
+**规则名称：**
+log_min_duration_statement不能为-1或者小于1000
+log_statement==all或mod可能会导致存储密集
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+log_min_duration_statement==-1,关闭了长查询的日志，可能难以定位和优化;
+
+log_min_duration_statement<1000报错,过小的查询也会写入日志，导致存储密集;
+
+log_statement==all或mod,导致存储密集;
+
+**影响：**
+1. 性能问题
+* 过多的日志记录：如果 log_min_duration_statement 设置为 -1 或一个非常低的值（如小于 1000 毫秒），几乎每个查询都会被记录。这会导致以下性能问题：
+* 日志写入负担：每个查询都需要写入日志，增加了数据库的 I/O 负担。在高并发的系统中，这种额外的日志写入可能会对数据库的整体性能产生显著影响，特别是在负载高峰期间。
+* 磁盘空间消耗：随着大量日志记录，磁盘空间会快速消耗，尤其是如果数据库正在处理大量的短时间查询时。长期运行可能会导致日志文件的膨胀，从而影响磁盘容量和数据库的正常运行。
+2. 日志管理和审计的复杂性
+* 日志冗余：记录大量查询的执行情况，尤其是小于 1000 毫秒的查询，会导致日志内容非常冗长。大量的短时查询日志会使得日志管理变得更加困难。管理员需要花费更多的时间来筛选出有意义的日志，增加了日志分析和审计的复杂度。
+* 信息过载：日志中包含大量无关的低延迟查询信息，可能会掩盖更重要的性能瓶颈或者问题，使得排查和定位数据库问题变得更加困难。
+3. 影响数据库响应时间
+* 增加延迟：每个查询记录都需要进行日志写入，如果数据库执行大量短时查询（如 SELECT 查询），这些查询的日志写入会消耗额外的系统资源，增加数据库响应时间。在高并发的情况下，这可能会导致显著的延迟，影响系统的实时性能。
+4. 可能导致无关查询的监控
+* 无效的数据收集：记录所有查询的执行时长，尤其是那些已经非常快的小查询，可能没有实际意义。你可能会收集到大量无关紧要的低延迟查询数据，从而浪费监控系统的资源。这样，关键的性能问题就可能被淹没在这些无关的日志中，降低了性能监控和故障排查的效率。
+5. 可能导致查询信息的泄漏
+* 过度的查询日志记录：在某些情况下，记录大量查询信息（即便是执行时间很短的查询）可能会无意中泄露数据库的查询模式、表结构或其他敏感数据，增加系统的安全风险。
+
+**检查方法：**
+```sql
+show log_statemen
+```
+```sql
+show log_min_duration_statement
+```
+判断log_statement的的值是否为all或mod,判断log_min_duration_statement的值是否为-1,或者小于1000
+
+**修复方法：**
+```bash
+gs_guc reload -Z datanode -N all -I all -c "log_min_duration_statement=%s" -c "log_statemen=none"
+gs_om -t stop && gs_om -t start
+```
+
+**参考来源：**
+无
+
 ## 备份配置
 
 ### OPENGAUSS.O_6.G_8.R_1：确保WAL信息记录级别配置正确
@@ -3608,7 +3994,7 @@ OPENGAUSS.O_6.G_8.R_1
 
 **规则背景说明：**
 
-WAL（Write Ahead Log）即预写式日志，是数据库用于恢复事务持久性的一种机制。`wal_level`决定了写入WAL的信息量。为了在备机上开启只读查询，`wal_level`需要在主机上设置成`hot_standby`，并且备机设置`hot_standby`参数为`on`。
+WAL（Write Ahead Log）即预写式日志，是数据库用于恢复事务持久性的一种机制。`wal_level`决定了写入WAL的信息量。为了在备机上开启只读查询，`wal_level`需要在主机上设置成`hot_standby`，并且备机设置`hot_standby`参数为`on`。对于分布式环境，不支持设置`hot_standby`为`off`，因此`wal_level`不可设置为`archive`或`minimal`，否则数据库将无法启动。建议设置`wal_level`参数为默认值`hot_standby`。
 
 **影响：**
 无
@@ -3850,15 +4236,205 @@ NTP（Network Time Protocol，网络时间协议）是同步网络中的各个
 **参考来源：**
 无
 
-## 其它配置
-
-### OPENGAUSS.O_6.G_10.R_1：确保backslash_quote参数配置正确
+### OPENGAUSS.O_6.G_9.R_4：maintenance_work_mem 应大于等于 64MB
 
 **配置组ID：**
-OPENGAUSS.O_6.G_10
+OPENGAUSS.G_9
 
-**配置组名称:**
-其它配置
+**配置组名称：**
+运行环境配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_9.R_4
+
+**规则名称：**
+maintenance_work_mem 应大于等于 64MB
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+如果maintenance_work_mem设置为64 MB（即64 * 1024字节）或更小，它会影响数据库的维护操作，比如VACUUM、CREATE INDEX和ALTER TABLE等任务
+
+**影响：**
+
+性能降低：较小的maintenance_work_mem会限制这些操作使用的内存，可能导致性能降低，因为这些操作需要更多时间来完成。
+
+操作效率：例如，在创建索引或执行大规模的VACUUM操作时，较小的内存设置可能会导致更多的磁盘I/O操作，从而增加操作时间。
+
+系统负荷：如果内存不足，可能会增加系统的负载，因为数据库可能会需要频繁地交换数据到磁盘。
+
+**检查方法：**
+
+```sql
+show maintenance_work_mem
+```
+查询maintenance_work_mem，进行单位换算,和64MB进行比较
+
+
+**修复方法：**
+
+调整maintenance_work_mem的大小应根据实际的系统资源和数据库的负载情况来优化，以提高维护任务的效率。
+
+```bash
+gs_guc set -Z datanode -N all -I all -c "maintenance_work_mem = %s"
+gs_om -t stop && gs_om -t start
+```
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_9.R_5：所有数据库相加的空间/shared_buffers 不应小于0.7
+
+**配置组ID：**
+OPENGAUSS.G_9
+
+**配置组名称：**
+运行环境配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_9.R_5
+
+**规则名称：**
+所有数据库相加的空间/shared_buffers 不应小于0.7
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+如果所有数据库的空间总和（即所有表、索引、系统对象等的总空间）相对于shared_buffers的设置较小（例如小于0.7倍的shared_buffers），可能会出现以下情况：
+缓存不完全:
+
+数据页覆盖: 由于shared_buffers的大小设置较小，数据库可能无法缓存所有活跃的数据页。这意味着如果数据库的工作集大小（即常用的数据）大于shared_buffers的设置，缓存将无法涵盖所有这些数据页，导致频繁的磁盘访问。
+性能瓶颈: 当工作集超过缓存容量时，数据库将频繁地将数据从磁盘加载到缓存中，造成性能瓶颈，增加响应时间和磁盘I/O负荷。
+内存利用率:
+
+内存利用不足: 如果shared_buffers设置得很小，系统的内存可能无法得到充分利用。虽然数据库可能不会耗尽物理内存，但缓存较小可能无法有效减少磁盘I/O，导致性能下降。
+缓存命中率低: 小的缓存会降低缓存命中率，即请求的数据页在缓存中存在的概率较低，从而增加了磁盘I/O操作。
+数据库性能:
+
+增加磁盘I/O: 小的shared_buffers会导致更多的磁盘读写操作，因为系统需要从磁盘读取数据，而不是从缓存中读取。这会增加磁盘I/O操作，可能导致性能下降，尤其是在负载较高或数据访问频繁的情况下。
+响应时间变长: 数据访问的响应时间可能会变长，尤其是在需要读取大量数据或进行复杂查询时，因为缓存的不足可能导致频繁的磁盘访问。
+
+**影响：**
+1. 性能下降
+* 磁盘 I/O 增加：shared_buffers 参数决定了数据库能够缓存的数据页数量。如果这个缓冲区过小，数据库在查询时需要频繁地从磁盘读取数据，增加了磁盘 I/O。频繁的磁盘 I/O 会显著降低数据库的性能，特别是在高负载或大数据量的情况下，导致查询响应变慢。
+* 降低缓存命中率：缓存命中率是衡量数据访问效率的重要指标。shared_buffers 较小意味着数据库能缓存的数据量减少，导致更多的访问请求需要从磁盘加载数据。缓存命中率低会直接影响数据库的查询效率和响应时间。
+2. 数据库性能瓶颈
+* 影响查询性能：如果 shared_buffers 配置过小，数据库查询时会更多地依赖磁盘存取，而磁盘的访问速度远低于内存。特别是在执行复杂查询、大量插入或更新操作时，磁盘 I/O 成为瓶颈，导致整体性能下降。
+* 增加延迟：过小的 shared_buffers 会增加数据交换的延迟，特别是在高并发情况下，多个客户端并发请求数据时，数据库更容易遭遇性能瓶颈。由于数据无法有效缓存，查询延迟可能显著增加。
+3. 增加系统负载
+* 频繁的磁盘交换（swapping）：当数据库无法有效地将数据缓存到内存中时，操作系统可能会将数据交换到磁盘上，这会增加系统的 I/O 负载，并可能导致 CPU 和内存的过度使用，进而影响数据库和其他系统进程的性能。
+* 内存不足导致的性能波动：如果 shared_buffers 太小，内存分配给数据库的空间不足，可能导致内存管理不当，影响系统的稳定性，并可能导致内存溢出或崩溃。
+4. 影响并发性能
+* 锁竞争与阻塞：在并发操作较多的情况下，较小的 shared_buffers 会导致频繁的缓存失效和页面置换，这可能加剧数据库内部的锁竞争，增加查询的等待时间，降低数据库的并发处理能力，影响系统响应速度和吞吐量。
+
+**检查方法：**
+
+1. all_databases_size：
+```sql
+select sum(pg_database_size(datname)) from pg_database;
+```
+2. shared_buffers
+```sql
+show shared_buffers
+```
+3. shared_buffers_usage
+```sql
+shared_buffers_usage = all_databases_size / shared_buffers
+```
+
+**修复方法：**
+
+根据内存调整: 通常建议shared_buffers设置为系统总内存的20%到40%。例如，如果你的系统总内存是16 GB，shared_buffers设置范围应在3.2 GB到6.4 GB之间，以达到最佳性能。
+监控和调整: 监控数据库的性能指标（如缓存命中率、磁盘I/O负荷等），并根据实际需求调整shared_buffers的配置。可以通过性能监控工具和日志分析来优化设置。
+```bash
+gs_guc set -Z datanode -N all -I all -c "shared_buffers = %s"
+gs_om -t stop && gs_om -t start
+```
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_9.R_6：查询时buffer 的命中率（即缓冲区命中率）不能高于 99.99% 或低于 90%
+
+**配置组ID：**
+OPENGAUSS.G_9
+
+**配置组名称：**
+运行环境配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_9.R_6
+
+**规则名称：**
+查询时对 buffer 的命中率（即缓冲区命中率）不能高于 99.99% 或低于 90%
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+1. 高于 99.99%
+    性能优越：极高的命中率表明大多数数据请求都从缓冲区中获取，减少了磁盘 I/O 操作，通常会导致查询响应时间非常快和系统性能优越。
+    内存利用率高：这种情况可能表示缓冲区配置得当，内存被有效利用。然而，也可能导致内存资源紧张，影响其他进程。
+2. 低于 90%
+    性能下降：低命中率表明大量的数据请求需要从磁盘中读取，这会增加 I/O 操作，导致查询响应时间变慢，系统性能下降。
+    需要调整：可能需要增加缓冲区大小或优化查询，确保更高比例的数据能留在缓冲区中，以减少磁盘访问频率。
+
+**影响：**
+1. 内存资源浪费
+
+* 当缓冲区命中率过高，说明大部分查询都能够从内存中读取数据。此时，数据库的内存缓冲区可能已被完全填充并且没有足够的空间来存储新的数据页。
+
+* 资源利用率低：内存中的数据页如果过多地重复使用，未能有效地将新数据加载到缓冲区中，导致部分内存资源可能没有得到充分利用。
+无法处理较大数据集：如果数据库需要处理大量的、动态变化的数据，过高的命中率可能会导致较小的缓冲区容量，限制了数据库的扩展性和性能。
+可能出现性能瓶颈
+
+* 缓冲区命中率过高有时可能是因为数据库缓存了过多的静态数据，或者查询的范围非常小。随着数据量的增长，过度依赖内存的缓存可能导致其他数据库操作的性能瓶颈，尤其是在数据访问模式发生变化时，可能无法及时适应。
+
+2. 较难检测潜在问题
+
+* 高命中率隐藏了数据库潜在的查询性能问题。比如，可能存在不优化的查询，查询总是命中缓存，却忽视了需要在更大的数据集上进行性能调优的必要性。
+
+**检查方法：**
+```sql
+select sum(idx_blks_hit)*100/(sum(idx_blks_read)+sum(idx_blks_hit)+1) from pg_statio_all_tables;
+```
+Shared_buffers_hit_rate和99.99, 90比较大小
+
+**修复方法：**
+
+合理配置: 通常，effective_cache_size 应该设置为比 shared_buffers 大，以便更准确地估算可用的缓存内存。例如，如果 shared_buffers 设置为 4GB，effective_cache_size 可以设置为 8GB 或更多，具体取决于系统的整体内存容量。
+
+监控和调整: 监控数据库的性能表现，并根据实际情况调整这些参数。定期检查和调整 shared_buffers 和 effective_cache_size 可以帮助维持最佳性能
+```bash
+gs_guc set -Z datanode -N all -I all -c "effective_cache_size = %s" -c "shared_buffers = %s"
+gs_om -t stop && gs_om -t start
+```
+**参考来源：**
+无
+
+
+
+## 其它配置
+
+### OPENGAUSS.O_6.G_10.R_1：确保backslash_quote参数配置正确
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称:**
+其它配置
 
 **规则ID:**
 OPENGAUSS.O_6.G_10.R_1
@@ -3950,5 +4526,938 @@ gs_guc set -Z datanode -N all -I all -c "allow_system_table_mods=off"
 gs_om -t stop && gs_om -t start
 ```
 
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_3：确保不存在会在未来7天内过期的用户
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_3
+
+**规则名称：**
+确保不存在会在未来7天内过期的用户
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+* 用户可能无法登录：如果数据库用户的密码到期，他们将无法再使用旧密码登录到数据库。这可能会导致系统管理员需要重置或更新用户的密码。
+
+* 运维困难：对于临时性账户或者权限不再需要的账户而言，这种账户过期可以作为一种安全机制。但是过多因为定期规则过期而使大量运维人员需要更新密码登陆等操作将增加运维工作量。
+
+**影响：**
+1. 安全隐患
+* 未及时更新权限：数据库用户的过期日期通常用于管理和控制访问权限。如果这些账户未能及时更新或清除，可能会导致未授权访问或者过期账户意外地被滥用。
+* 权限管理混乱：如果用户过期管理不当，过期账户可能在权限控制上产生混乱，增加了管理员在管理过程中漏掉过期账户的风险，从而降低了数据库的安全性。
+* 账户被滥用的风险：如果过期的用户账户仍然存在且没有被禁用，恶意用户或攻击者可能会利用这些过期账户执行不必要的操作，甚至进行数据窃取、篡改或破坏。
+2. 系统资源浪费
+* 无效账户增加负担：存在过期的用户账户会占用数据库的资源，例如存储、用户会话和连接资源。尽管过期账户不会实际登录，但仍然存在于数据库中，增加了系统的管理复杂度和数据库的资源占用。
+* 维护成本增加：管理员需要额外的时间和精力来检查、管理和清理过期账户，这增加了数据库运维的成本。
+3. 合规性和审计问题
+* 合规风险：在某些行业中，合规性要求数据库管理账户的有效性和过期管理。如果数据库中存在过期的账户未及时清除或禁用，可能会违反合规要求，导致审计失败或法律风险。
+* 审计困难：过期用户账户如果没有被清除，可能会在审计日志中造成干扰，难以准确判断哪些账户在实际使用中，以及是否存在异常的账户活动。
+4. 数据库性能下降
+* 不必要的账户验证：过期账户仍然存在于数据库系统中，每次验证用户登录时，数据库需要检查账户是否有效，这可能会带来额外的性能开销，尤其是在数据库存在大量用户的情况下。
+* 锁表和资源竞争：如果过期的用户账户仍然占用连接或会话资源，可能导致数据库连接池压力过大，从而影响正常用户的查询性能和响应速度。
+
+**检查方法：**
+
+查询结果是否为空。
+
+```sql
+select usename from pg_user where valuntil < now() + interval '7 days'
+```
+
+**修复方法：**
+
+* 及时通知用户：提前通知即将过期的用户，并要求其及时修改密码或进行相应操作以避免影响正常服务。
+
+* 自动化处理：通过自动化脚本、定时任务等方式对即将到期的用户进行扫描和处理，自动重置、延长有效期或禁用不再需要的账号。
+
+* 完善权限管理流程：设计合理完善权限管理策略和审计机制，在确保安全可控的情况下降低因为账号失效带来影响。
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_4：当前用户为superuser时,密码和用户名不能相同
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_4
+
+**规则名称：**
+存在密码和用户名相同的用户则报错“存在不安全的用户密码”，仅在当前用户为superuser时
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+在OpenGauss数据库中，如果系统存在用户名和密码相同的用户，可能会导致“存在不安全的用户密码”报错。此错误表示用户的密码设置为与用户名相同，这是一个常见的安全漏洞，因为它容易被猜测或暴力破解，可能会让数据库系统面临安全风险。
+
+Superuser检查: 在OpenGauss中，只有当当前用户具有superuser权限时，系统才会执行此项检查。这是因为superuser拥有更高的权限，可以影响数据库的整体安全性。
+
+**影响：**
+1. 容易受到暴力破解攻击
+* 暴力破解攻击风险增加：如果超级用户的用户名和密码相同，那么攻击者只需猜测用户名（通常为 "superuser" 或类似的默认超级用户名），就能直接尝试与其相同的密码进行暴力破解攻击。这使得密码变得极易被破解。
+* 密码猜测简单：用户名和密码相同的情况下，攻击者只需要猜测一个值，而不是需要两个不同的复杂字符序列，大大降低了攻击难度。
+2. 违反安全最佳实践
+* 违反密码复杂性要求：大多数安全标准（如 NIST 和 ISO/IEC 27001）要求密码具有一定的复杂性，包括长度、字符种类和不可预测性。当用户名和密码相同，密码的复杂性显著降低，容易受到攻击。
+* 单一的安全弱点：用户名和密码相同的方式是安全性极低的配置。这意味着一旦攻击者知道了这个用户名，他们就能够轻松地猜测密码。
+3. 增加内部威胁风险
+* 滥用的可能性：如果数据库管理员或具有超级用户权限的人员忘记了他们的密码或者账户设置不当，攻击者可能会利用这种简单的密码组合进行恶意操作。
+* 社交工程攻击风险：攻击者可以通过社交工程手段获取用户名，然后直接猜测密码（如相同）。如果密码和用户名相同，这种攻击方式会非常高效。
+4. 增加账户被滥用的风险
+* 账户滥用：一旦超级用户账户被泄露或被恶意用户获得，因用户名与密码相同，账户会极易被滥用。超级用户权限可以直接访问和修改数据库中的所有数据，导致数据丢失、泄露或篡改。
+* 对整个数据库安全性构成威胁：超级用户账户拥有最高权限，其泄露或滥用会使得整个数据库和其中的数据面临极大的安全风险。
+
+**检查方法：**
+
+查询结果是否为空。
+
+```sql
+select usename from pg_shadow where passwd='md5'||md5(usename||usename)
+```
+
+**修复方法：**
+
+* 修改密码: 需要将这些不安全的密码更改为更复杂、与用户名不相同的密码。这可以通过数据库的管理工具或SQL命令来完成。
+* 例如，使用ALTER USER语句来修改用户的密码。
+* 审计和清理: 定期审计数据库用户账户，确保没有安全风险。如果发现存在此类不安全的账户，及时进行处理和整改。
+示例操作:
+
+修改密码的SQL命令:
+```sql
+ALTER USER username WITH PASSWORD 'new_secure_password';
+```
+检查现有用户: 可以编写脚本或使用SQL查询来检查用户的密码策略和现有用户账户，确保符合安全标准。
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_5：避免存在第一阶段未提交事务
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_5
+
+**规则名称：**
+
+prepared_xact_count!=0,当前存在第一阶段未提交事务
+
+prepared_xact_count!=0且prepared_xact_lock_count>0,当前存在两阶段事务锁
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+当 prepared_xact_count 不等于 0 时，表示系统中存在一个或多个已经准备但尚未提交或回滚的事务。具体影响包括：
+
+事务状态:
+
+* 这些事务已经通过了预备阶段，意味着它们已经成功执行了所有操作，但还没有进入提交阶段。系统处于等待进一步操作的状态。
+资源占用:
+
+* 准备好的事务可能会占用系统资源，包括锁和日志空间。如果这些事务长时间处于准备状态，它们可能会导致资源的积压。
+事务一致性和完整性:
+
+* 如果这些准备好的事务长时间未完成（即未提交或回滚），可能会影响数据库的一致性和完整性，尤其是在恢复操作或系统故障时。
+故障恢复和事务处理:
+
+* 在系统重启或恢复时，数据库需要处理这些准备好的事务。通常，这意味着数据库需要回滚这些事务或提交它们，以确保数据库的一致性。
+性能影响:
+
+* 大量的准备好事务可能会影响数据库性能，因为系统需要管理这些事务的状态，并且可能会导致锁竞争或日志写入问题。
+
+当 prepared_xact_count 不等于 0 且 prepared_xact_lock_count 大于 0 时，系统报告错误 "当前存在两阶段事务锁" 表示当前有两个或更多的两阶段事务锁（即准备好的事务）存在，这可能会对数据库的正常操作产生影响。具体影响和应对措施如下：
+
+* 数据库可能会限制某些操作，特别是涉及锁定或修改数据的操作，因为现有的两阶段事务锁可能会阻塞这些操作。
+性能下降:
+
+* 由于这些两阶段事务锁，数据库在处理其他事务时可能会遇到性能瓶颈。例如，等待这些事务完成或回滚可能会导致其他事务的延迟。
+资源占用:
+
+* 两阶段事务锁会占用系统资源，包括锁和日志空间。这可能会影响数据库的整体性能和资源使用效率。
+事务一致性问题:
+
+* 如果这些事务长时间未完成（即未提交或回滚），可能会影响数据库的一致性和完整性，特别是在故障恢复过程中。
+
+**影响：**
+1. 数据一致性问题
+* 脏数据写入风险：如果事务在第一阶段挂起且未提交，其他事务或查询可能会读取到尚未确认的数据，这可能导致 脏读（Dirty Read）。虽然 openGauss 支持 可串行化隔离级别，但在某些配置或特殊场景下，未提交的事务仍可能影响数据的一致性。
+* 不一致的查询结果：未提交的事务可能导致在并发查询时返回不一致的结果。其他事务在读取数据时，可能会看到正在修改但尚未提交的数据，进而影响查询的正确性。
+2. 数据库性能下降
+* 锁资源争用：未提交的事务会持有数据库锁，尤其是在 行级锁 或 表级锁 等情况下。这样会导致其他事务无法访问被锁定的数据，可能会发生 死锁 或 锁等待，导致系统性能大幅下降，甚至事务超时。
+* 事务队列增长：当多个事务处于未提交状态时，数据库的事务队列会增长，增加事务调度和资源管理的开销。这可能导致 事务提交延迟，系统响应速度变慢，尤其是在事务量较大的情况下。
+3. 事务隔离级别失效
+* 隔离性降低：数据库的 事务隔离级别 旨在确保并发事务不会互相干扰，但如果存在未提交的事务，可能导致隔离性无法得到有效保障。例如，在较低隔离级别（如 读已提交 或 可重复读）下，其他事务可能会读取到尚未提交的修改，从而破坏隔离性。
+* 不可预测的行为：未提交事务可能引发不可预测的行为，尤其是当事务在提交前发生回滚时，其他事务可能依然读取到该事务的数据变更，增加系统的不稳定性。
+
+**检查方法：**
+
+查看prepared_xact_count的值是否为0
+```sql
+select count(1) from pg_prepared_xacts;
+```
+查看prepared_xact_lock_count的值是否大于0
+```sql
+select count(1) from pg_locks where transactionid in (select transaction from pg_prepared_xacts)
+```
+检查prepared_xact_count != 0
+
+检查prepared_xact_count != 0 并且 prepared_xact_lock_count > 0
+
+**修复方法：**
+
+检查未完成的事务:
+
+* 使用数据库管理工具或SQL查询来检查哪些事务处于准备状态，并确定它们的状态和原因。
+完成或回滚事务:
+
+* 尽快完成（提交）或回滚这些准备好的事务。可以使用以下 SQL 命令来查看和处理这些事务（实际命令可能根据数据库版本和工具有所不同）：
+
+```sql
+SELECT * FROM pg_prepared_xacts;
+```
+
+根据查询结果，确定如何处理这些事务。
+
+调整事务管理配置:
+
+* 确保事务管理的配置和两阶段提交协议的实施是正确的。优化事务处理流程，减少事务锁的持有时间。
+监控和维护:
+
+* 定期监控 prepared_xact_count 和 prepared_xact_lock_count 的值，确保数据库在正常运行中不会积累过多的准备事务。
+错误处理:
+
+* 如果遇到该错误，处理方式可能包括从数据库中手动清理这些事务，或重新启动数据库以清理可能的事务锁（但请谨慎操作，以避免数据丢失）。
+更新和修复:
+
+* 确保数据库是最新版本，应用所有可用的修复和更新，避免已知的错误或漏洞影响系统。
+
+查看当前的准备事务：
+```sql
+SELECT * FROM pg_prepared_xacts;
+```
+提交准备好的事务：
+
+```sql
+COMMIT PREPARED 'transaction_id';
+```
+
+回滚准备好的事务：
+
+```sql
+ROLLBACK PREPARED 'transaction_id';
+```
+
+在处理这些问题时，确保了解每个事务的上下文和状态，避免不必要的数据丢失或数据库不一致。
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_6：参数autovacuum应设置为on
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_6
+
+**规则名称：**
+参数autovacuum应设置为on
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+如果 autovacuum 设置为 off，OpenGauss 数据库不会自动执行垃圾回收和统计信息更新。这可能导致表中的已删除或更新的数据行无法及时清理，最终导致表膨胀，影响数据库性能，并且查询优化器使用的统计信息可能不准确，导致查询性能下降
+
+**影响：**
+1. 表膨胀（Table Bloat）
+* 死行积累：在数据库中，执行删除或更新操作时，原先的数据不会立即被物理删除，而是被标记为“死行”。如果 autovacuum 被禁用，这些死行将一直保留在数据库中，导致 表膨胀（Bloat）。
+* 存储空间浪费：死行占用的空间不会被回收，最终可能导致表和索引的大小不断增长，浪费大量存储资源。特别是在频繁更新或删除数据的环境中，表膨胀的风险更大。
+2. 性能下降
+* 查询性能下降：当表膨胀严重时，查询时需要扫描大量无用的死行，这会显著增加扫描时间，降低查询性能。数据库可能需要更多的内存和 CPU 来处理这些冗余数据。
+* 索引效率降低：如果表膨胀发生在有索引的列上，索引也会膨胀，导致查询时索引扫描的效率降低，进而影响整体查询响应速度。
+3. 磁盘空间耗尽
+* 磁盘空间不足：随着死行积累，数据库占用的磁盘空间不断增加，最终可能导致磁盘空间不足。在数据库需要更多空间时，无法及时释放资源，可能导致数据库性能下降，甚至无法正常工作。
+* 数据备份问题：随着数据库的膨胀，备份数据的体积也会增加，备份和恢复的时间会显著延长，增加运维压力。
+4. 事务ID Wraparound 问题
+* 事务ID溢出：在 openGauss（和 PostgreSQL）中，每个数据行都与一个事务 ID（Transaction ID）关联。当事务 ID 累计达到一定数量时，如果没有及时执行 vacuum 操作，会导致事务 ID 溢出（事务 ID Wraparound）。这可能会导致数据丢失、损坏，甚至使数据库变得不可用。
+* 数据一致性问题：事务 ID 溢出时，旧事务会被误认为已经提交，从而导致数据库中的数据不一致，甚至丧失完整性。
+5. 锁表和长时间的清理操作
+* 手动清理负担：如果关闭了 autovacuum，管理员必须手动执行 VACUUM 操作。手动清理时，由于表膨胀可能需要处理大量的死行，这样的操作会变得非常耗时。清理时需要对表加锁，可能会影响到数据库的正常运行，导致应用不可用或响应缓慢。
+* 高并发环境下的性能瓶颈：在高并发环境中，如果没有定期进行 vacuum，数据库可能会经历较长时间的锁表过程，导致系统的响应延迟，甚至影响整体的用户体验。
+
+
+**检查方法：**
+
+查看autovacuum的值是否为on
+```sql
+show autovacuum;
+```
+
+**修复方法：**
+```bash
+gs_guc set -Z datanode -N all -I all -c "autovacuum = on"
+gs_om -t stop && gs_om -t start
+```
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_7：确保checkpoint_warning不为0,checkpoint_completion_target不为0
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_7
+
+**规则名称：**
+
+确保checkpoint_warning不为0,checkpoint_completion_target不为0
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+* 将 checkpoint_warning 设置为 0 会禁用警告消息。当 checkpoint_warning 设置为 0 时，数据库不会在检查点（checkpoint）操作时发出警告消息，这可能会错过有关潜在性能问题的提示。
+* 将 checkpoint_completion_target 设置为 0 会使数据库在执行检查点（checkpoint）时尽可能快地完成，而不是在预定时间内平滑完成。这样可能会导致：
+1. 高 I/O 峰值：检查点会集中在较短的时间内完成，可能会导致 I/O 瓶颈和系统负载增加。
+2. 性能波动：由于集中写入，数据库性能可能会在检查点期间显著下降。
+3. 恢复时间延长：检查点的恢复过程可能会变得较长，因为所有数据都在短时间内写入到磁盘
+
+**影响：**
+1. 缺乏检查点时间警告 (checkpoint_warning = 0)
+* 无法提前发现性能瓶颈：checkpoint_warning 设为 0 后，数据库不会在检查点操作时间过长时发出警告。检查点操作是周期性的，如果过多的检查点操作消耗了过多时间，可能会导致数据库响应延迟，影响系统性能。但没有警告会导致管理员无法及时发现和调整。
+* 隐藏潜在问题：没有警告可能掩盖了数据库系统的性能问题。例如，可能存在 I/O 压力过大、缓冲池管理不当等问题，直到性能问题变得严重时才被发现。
+2. 频繁的磁盘I/O操作 (checkpoint_completion_target = 0)
+* 突然增加磁盘I/O负载：checkpoint_completion_target = 0 意味着数据库在检查点期间会尽量加速写入操作。这可能会导致数据库在执行检查点时对磁盘的负载非常高，尤其是在有大量脏页的情况下。高负载的磁盘I/O可能会导致：
+* 系统其他操作的响应变慢
+* 长时间的I/O等待，影响数据库整体性能
+* 写入延迟：如果系统没有足够的磁盘带宽或者硬件资源，在高I/O负载的情况下，可能会导致检查点无法在合理时间内完成，进而影响数据库的稳定性和响应能力。
+3. 数据库性能下降
+* 阻塞写入操作：当检查点快速进行时，可能会阻塞一些写入操作。由于 checkpoint_completion_target = 0 意味着检查点操作要尽快完成，可能会导致大量内存中的数据被强制写入磁盘，这会带来大量的 I/O 操作，增加磁盘延迟。
+* 性能波动：频繁的高I/O操作可能导致数据库的性能波动，影响查询和事务的响应时间。对于高并发的数据库环境，这种波动可能会更明显。
+4. 持久化不一致风险
+恢复时间延长：如果数据库频繁进行大规模的检查点操作，可能会导致大量脏页被迅速刷新到磁盘。这虽然有助于确保数据持久性，但过于频繁的操作可能导致在数据库崩溃时需要更多的恢复时间，因为检查点间的时间间隔变短，恢复时需要重放更多的日志。
+* 日志管理压力：如果检查点操作过于频繁且没有适当的警告，可能会导致日志文件积累过快，这会增加日志管理的复杂度。
+
+**检查方法：**
+
+查看checkpoint_completion_target
+```sql
+show checkpoint_completion_target;
+```
+查看checkpoint_warning
+```sql
+show checkpoint_warning;
+```
+判断是否为0
+
+**修复方法：**
+
+```bash
+gs_guc set -Z datanode -N all -I all -c "checkpoint_completion_target = %s" -c "checkpoint_warning=%s"
+gs_om -t stop && gs_om -t start
+```
+checkpoint_completion_target数值在0.5~0.7范围内比较平衡
+
+**参考来源：**
+无
+
+
+### OPENGAUSS.O_6.G_10.R_8：确保wal_sync_method为开启状态；synchronize_seqscans为开启状态
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_8
+
+**规则名称：**
+
+wal_sync_method为开启状态,synchronize_seqscans为开启状态
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+wal_sync_method 控制写前日志（WAL）同步的方法。如果关闭或不设置此参数，可能会有以下影响：
+* 数据一致性风险：WAL 的同步机制确保了数据在写入磁盘前被持久化。关闭此参数可能会导致在系统崩溃时数据丢失，因为 WAL 可能尚未完全写入磁盘。
+* 性能提升：在某些情况下，关闭同步可能会提高性能，因为它减少了写操作的同步开销，但这通常是以数据安全性为代价的。
+* 潜在的数据丢失：如果 WAL 没有同步到磁盘，数据库崩溃时可能会丢失尚未写入磁盘的数据，影响恢复能力
+
+synchronize_seqscans 参数控制是否同步执行序列扫描的操作。关闭该参数可能会有以下影响：
+* 性能提升：关闭 synchronize_seqscans 可以提高性能，特别是在多个并发序列扫描操作时，因为它允许这些操作不必同步执行，从而减少等待时间和锁竞争。
+* 可能的性能不稳定：禁用同步可能会导致序列扫描操作之间的协调不一致，尤其是在负载较高的情况下。这可能会影响查询性能或引发意外的行为。
+* 数据一致性：虽然对数据一致性的影响较小，但在一些极端情况下，可能会遇到未同步的扫描状态，这可能影响查询结果的一致性
+* 
+**影响：**
+1. 数据丢失风险：如果 wal_sync_method 没有开启合适的同步方法，可能会导致 WAL 日志未完全写入磁盘。这意味着在数据库崩溃或者系统故障时，尚未同步到磁盘的日志可能会丢失，从而导致部分事务丢失或数据不一致。
+
+2. 系统崩溃恢复延迟：当系统崩溃时，如果没有适当的 WAL 同步机制，数据库恢复可能会变得更加缓慢，恢复时间会显著增加。
+
+3. 性能问题：虽然同步 WAL 可以增加稳定性，但过于频繁地同步 WAL 也会影响性能，特别是在高负载情况下。如果 wal_sync_method 设置不合理，可能会在性能和数据安全之间产生不必要的权衡。
+
+
+
+**检查方法：**
+
+查询wal_sync_method的值
+```sql
+show wal_sync_method;
+```
+查询wal_sync_method的值
+```sql
+show synchronize_seqscans;
+```
+判断wal_sync_method是否为'fsync_writethrough',synchronize_seqscans是否为'on'
+
+**修复方法：**
+
+```bash
+gs_guc set -Z datanode -N all -I all -c "synchronize_seqscans = on" -c "wal_sync_method = 'fsync_writethrough'"
+gs_om -t stop && gs_om -t start
+```
+
+**参考来源：**
+无
+
+
+### OPENGAUSS.O_6.G_10.R_9：避免wal_level参数为minimal
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_9
+
+**规则名称：**
+避免wal_level参数为minimal
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+wal_level 设置为 'minimal' 会有以下影响：
+
+1.最小的 WAL 记录：wal_level 设置为 'minimal' 仅记录对数据库恢复所必需的最基本信息。这有助于减少 WAL 的生成量，从而减轻 I/O 负担和存储需求。
+
+2.限制功能：此设置将限制某些功能，如逻辑复制和某些类型的备份操作，因为这些功能需要更多的 WAL 信息来支持数据的恢复和同步。
+
+3.备份恢复：在 'minimal' 模式下创建的备份只能用于恢复到创建备份时的状态，而无法进行增量恢复或利用逻辑复制。
+**影响：**
+1. 无法进行增量备份
+* 增量备份不可用：wal_level = minimal 会极大地减少 WAL 日志的详细记录，导致无法进行基于 WAL 的增量备份。增量备份是通过记录自上次备份以来发生的变化来减少备份的数据量。如果没有增量备份，进行全量备份将消耗更多的存储空间和时间。
+2. 无法启用逻辑复制
+* 逻辑复制不可用：wal_level = minimal 级别不支持逻辑复制（Logical Replication）。逻辑复制需要较为详细的 WAL 日志记录，以便识别数据更改（如 INSERT、UPDATE、DELETE 等操作）。因此，在 wal_level = minimal 设置下，无法使用逻辑复制功能进行数据同步。
+3. 数据库恢复受限
+* 恢复选项受限：设置 wal_level = minimal 会限制数据库的恢复选项。WAL 日志的详细程度不足以支持某些类型的数据库恢复（如点-in-time 恢复）。在这种情况下，如果数据库发生崩溃，恢复过程可能不完整或无法恢复到特定的时间点。
+
+* 失去事务日志的详细信息：对于一些更复杂的恢复操作（如恢复到特定时间点，或恢复到某个特定事务），由于 WAL 日志信息过于简化，无法提供充分的细节，恢复的灵活性和准确性受到严重影响。
+
+
+
+**检查方法：**
+
+查询wal_level的值是否为minimal
+```sql
+show wal_level;
+```
+
+**修复方法：**
+
+调整 wal_level:
+```bash
+gs_guc set -Z datanode -N all -I all -c "wal_level = 'hot_standby'"
+gs_om -t stop && gs_om -t start
+```
+或者
+```sql
+ALTER SYSTEM SET wal_level = 'hot_standby';
+```
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_10：检查planner
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_10
+
+**规则名称：**
+
+有planner相关的cost参数非默认值则报错“可能导致planner得不到最优计划”
+有plan相关的function被关闭则报错，这里的判断标准是以enable_开头的配置项
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+如果调整了与查询计划生成器（planner）相关的 cost 参数且使用了非默认值,会导致查询性能下降：非默认的 cost 参数可能导致查询规划器选择不最优的执行计划，从而影响查询性能。
+有plan相关的function被关闭可能导致查询执行性能下降，因为优化器无法使用特定的优化策略或算法。
+
+**影响：**
+影响查询性能
+
+**检查方法：**
+执行如下SQL语句检查是否有查询结果：
+
+```sql
+select name from pg_settings where name like '%cost%' and setting<>boot_val;
+
+```
+```sql
+select name, setting from pg_settings where name like 'enable_%' and setting='off' ;
+```
+
+**修复方法：**
+
+1.恢复默认值：如果出现问题，考虑将这些 cost 参数恢复到默认值，以确保 planner 可以生成最优的查询计划。
+```sql
+ALTER SYSTEM RESET <cost_parameter>;
+```
+2.重新启用功能：查找被禁用的 enable_ 配置项，并将其重新启用。例如：
+```sql
+ALTER SYSTEM SET enable_<feature> = true;
+```
+
+
+**参考来源：**
+无
+
+
+### OPENGAUSS.O_6.G_10.R_11：检查是否有无效索引,未使用的索引
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_11
+
+**规则名称：**
+
+有无效索引则报错,有未使用的索引则报错
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+1.无效索引的影响：
+*  性能问题：无效索引（例如由于表结构变化或数据类型不匹配而导致的索引问题）可能导致查询计划中的问题，影响性能。
+*  存储浪费：无效索引会占用磁盘空间，但不会实际用于查询优化，浪费存储资源。
+*  维护负担：无效索引会增加数据库的维护复杂性，例如在进行索引重建或维护操作时需要额外的处理。
+
+2.未使用索引的影响：<br />
+* 性能开销：未使用的索引会增加数据修改操作（如插入、更新、删除）的开销，因为每次数据变动时都需要更新这些索引。
+*  存储开销：未使用的索引会占用额外的存储空间。
+*  维护复杂性：未使用的索引增加了数据库管理的复杂性。
+
+**影响：**
+* 查询性能下降：无效索引无法被数据库优化器利用，因此会增加查询执行的复杂度，导致查询性能下降。数据库会尝试使用其他可用的索引或扫描整个表，影响响应时间。
+
+* 存储空间浪费：无效索引仍然占用磁盘空间。虽然这些索引不可用，但它们仍然存在于数据库中，浪费了存储资源。
+
+* 增加维护复杂度：无效索引可能影响数据库的管理和维护工作，导致 DBA 必须额外检查和清理这些无效索引，增加了维护成本。
+
+* 影响数据库备份和恢复：无效索引会占用备份数据的空间，虽然其本身无法提高性能，但它们会增加备份的大小和恢复时的工作量。
+
+**检查方法：**
+执行如下SQL语句检查是否有查询结果：
+
+```sql
+SELECT  concat(n.nspname, '.', c.relname) as index FROM pg_catalog.pg_class c,pg_catalog.pg_namespace n,pg_catalog.pg_index i WHERE   i.indisvalid = false AND  i.indexrelid = c.oid AND c.relnamespace = n.oid; 
+```
+
+**修复方法：**
+
+处理无效索引的方法：
+
+1.检测无效索引：
+
+通过查询系统视图来识别无效索引。例如：
+
+```sql
+SELECT indexrelid::regclass AS index_name
+FROM pg_index
+WHERE indisvalid = FALSE;
+```
+2.重建无效索引：
+
+对于被标记为无效的索引，尝试重建索引：
+
+```sql
+REINDEX INDEX index_name;
+```
+
+3.删除无效索引：
+
+如果确认某些索引无效且不再需要，可以删除它们：
+```sql
+ DROP INDEX index_name;
+```
+
+处理未使用索引的方法：
+
+1.检测未使用的索引： 
+
+可以通过系统视图或性能监控工具来识别未使用的索引。一个常用的方法是查询 pg_stat_user_indexes 视图：
+
+```sql
+SELECT
+relname AS table_name,
+indexrelname AS index_name,
+idx_scan AS number_of_scans
+FROM
+pg_stat_user_indexes
+WHERE
+idx_scan = 0;
+```
+这个查询会列出那些未被扫描（即未被使用）的索引。
+
+2.评估和删除未使用的索引：
+
+在删除任何索引之前，建议先评估其潜在影响。可以通过以下步骤操作：
+
+测试影响：在非生产环境中测试删除未使用索引的影响。
+
+删除索引：确认无负面影响后，删除未使用的索引：
+
+```sql
+DROP INDEX index_name;
+```
+
+3.定期审查和维护：
+
+定期审查索引的使用情况，并进行必要的维护。使用工具或脚本来自动检测和处理未使用的索引。
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_12：检查overcommit_memory和overcommit_ratio
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_12
+
+**规则名称：**
+
+建议overcommit_memory设置为2,
+overcommit_ratio设置区间(50~90)
+
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+overcommit_memory = 0（默认值）：内核会根据算法估算总内存需求，并在实际分配内存时考虑系统的剩余内存。这种模式允许更多的内存请求，但有时可能导致内存不足的情况，特别是当实际内存需求超出预期时。
+
+overcommit_memory = 1：内核会允许所有内存分配请求，即使当前系统内存不足。这种模式降低了内存分配失败的概率，但增加了系统因内存不足而崩溃的风险。
+
+设置overcommit_memory为2有助于提高系统稳定性，但需要根据具体的应用场景和需求来选择合适的设置
+
+**影响：**
+影响系统稳定性
+
+**检查方法：**
+执行如下命令
+
+```bash
+cat /proc/sys/vm/overcommit_memory
+
+```
+```bash
+cat /proc/sys/vm/overcommit_ratio
+```
+overcommit_memory!=2时报错可能导致opengauss被omm杀掉
+overcommit_memory!=2且overcommit_ratio<50时报错利用率过低
+overcommit_memory!=2且overcommit_ratio>90时报错可能导致内存不足
+
+**修复方法：**
+* 建议将overcommit_memory值设为2
+* overcommit_ratio设置为50~90之间
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_13：确保wal_sync_method参数为fsync
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_13
+
+**规则名称：**
+
+darwin系统中wal_sync_method != 'fsync'则报错“可能导致崩溃后的数据丢失”
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+darwin系统中wal_sync_method 不是'fsync'可能导致崩溃后的数据丢失
+
+**影响：**
+1. 数据丢失风险
+fsync 是一种常用的同步方法，能够确保 WAL 日志数据在写入时被立即同步到磁盘。若 wal_sync_method 参数未设置为 fsync，数据库可能会使用其他同步方法（如 fdatasync 或 open_sync），这些方法可能会导致 WAL 日志在写入后并未立即同步到磁盘。若系统崩溃或发生断电等故障，尚未同步到磁盘的 WAL 数据可能会丢失，从而导致部分事务丢失，影响数据一致性和完整性。
+
+2. 数据库恢复时间延长
+WAL 日志是 PostgreSQL 和 openGauss 数据库恢复过程中不可或缺的一部分。当系统发生崩溃时，数据库会从 WAL 日志中恢复事务。如果 WAL 数据未完全同步到磁盘，恢复时可能会丢失一些尚未写入磁盘的事务记录，进而延长恢复时间或使得部分数据无法恢复。
+
+3. 数据一致性问题
+如果未使用 fsync，其他的同步方法可能并不保证数据在磁盘上的实际持久性。即使数据库认为数据已经写入 WAL，实际上它可能仍在内存缓存中，未完全写入磁盘。这可能导致在系统异常关闭时，部分数据丢失，导致数据库的状态与实际事务不一致。
+
+**检查方法：**
+
+执行命令查看系统是否是darwin
+```bash
+uname -s
+```
+执行sql查看wal_sync_method的状态
+```sql
+show wal_sync_method
+```
+先查看系统是否为darwin,是darwin在去检查wal_sync_method的状态
+
+**修复方法：**
+
+评估需求：
+
+* 确定你的应用程序对数据一致性的要求和对性能的期望。
+* 选择合适的wal_sync_method：
+
+* 如果数据一致性至关重要，fsync。这将确保每次写操作都被同步到磁盘。
+* 如果可以接受一定的数据丢失风险以换取更高的性能，可以选择fsync或fdatasync。
+
+配置wal_sync_method：
+
+* 修改OpenGauss配置文件中的wal_sync_method设置。例如，编辑postgresql.conf,设置wal_sync_method参数：
+* wal_sync_method = 'fsync'
+* 重新加载配置或重启数据库以使更改生效。
+```bash
+gs_guc set -Z datanode -N all -I all -c "wal_sync_method = 'fsync'"
+gs_om -t stop && gs_om -t start
+```
+
+**参考来源：**
+无
+
+
+### OPENGAUSS.O_6.G_10.R_14：确保enable_huge_pages为off
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_14
+
+**规则名称：**
+
+确保enable_huge_pages为off,enable_huge_pages为on可能导致数据库无法启动
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+将 enable_huge_pages 设置为 on 可能导致 OpenGauss 数据库无法启动的原因包括：
+
+* 操作系统配置问题：系统未正确配置大页内存（例如未分配足够的大页），导致数据库无法获得所需的内存。
+
+* 权限问题：数据库进程可能没有足够的权限来使用大页内存，或者操作系统的权限设置不允许数据库使用大页内存。
+
+* 内存不足：系统中可用的大页内存不足以满足数据库的需求，导致启动失败。
+
+* 兼容性问题：数据库和操作系统之间可能存在不兼容的问题，导致无法正确使用大页内存。
+
+**影响：**
+1. 兼容性问题：
+
+* 并非所有的操作系统和硬件都支持 Huge Pages。启用 Huge Pages 后，可能会出现与操作系统或硬件的不兼容情况。
+* 如果操作系统或硬件没有正确配置 Huge Pages 或不支持此特性，可能会导致数据库启动失败或出现内存分配错误。
+2. 资源浪费：
+
+* 启用 Huge Pages 后，操作系统会在启动时预先分配一定数量的内存页。如果实际需求不大，可能会导致内存的浪费。对于内存紧张的系统，可能会导致操作系统无法为其他进程分配足够的内存。
+3. 内存碎片问题：
+
+* 如果启用了 Huge Pages，而数据库的内存需求并不大或不均匀分布，可能会导致内存的碎片化问题。尤其是当数据库频繁启动和关闭时，内存的预分配和释放可能会导致内存碎片，这反过来可能影响性能
+
+**检查方法：**
+
+执行sql查看enable_huge_pages的状态
+```sql
+show enable_huge_pages
+```
+
+**修复方法：**
+
+```bash
+gs_guc set -Z datanode -N all -I all -c "enable_huge_pages = off"
+gs_om -t stop && gs_om -t start
+```
+
+**参考来源：**
+无
+
+### OPENGAUSS.O_6.G_10.R_15：配置依赖规则
+
+**配置组ID：**
+OPENGAUSS.O_6.G_10
+
+**配置组名称：**
+其它配置
+
+**规则ID：**
+OPENGAUSS.O_6.G_10.R_15
+
+**规则名称：**
+
+配置依赖规则检测
+
+**级别：**
+要求
+
+**相关要求：**
+无
+
+**规则背景说明：**
+
+gauss数据库管理系统有数百个配置参数，这些参数控制了系统的内存分配、I/O优化、备份与恢复等诸多方面，并极大地影响了数据库的吞吐量、延迟等性能。参数调优技术通过调整数据库参数配置来优化数据库性能。传统参数调优面临着许多困难，主要体现在以下几方面：
+* 1.参数数量众多（数以百计，且作用各不相同）
+* 2.参数间不独立（更改一项参数可能会影响其他参数）
+* 3.配置不通用（不同工作负载以及不同应用程序下的最优参数配置并不相同）
+
+
+**影响：**
+对系统稳定性有一定的影响
+
+**检查方法：**
+目前基于程序分析方法提取的规则分为单节点规则和多节点规则，分别位于“rules_single_node.csv”和“rules_multi_node.csv”中
+动态读取信息并进行根据专家知识（MySQLTuner和PgSQLTuner中适配的规则）分析;并且这一模式下，多配置依赖检测的参数取值读取自pg_setting表
+
+```sql
+SELECT json_agg(json_build_object(
+    'name', name, 
+    'setting', setting,
+    'unit', unit, 
+    'category',category,
+    'short_desc', short_desc,
+    'extra_desc', extra_desc,
+    'context', context,
+    'vartype', vartype, 
+    'source', source, 
+    'min_val', min_val, 
+    'max_val', max_val, 
+    'enumvals', enumvals, 
+    'boot_val', boot_val, 
+    'reset_val', re[rag-secret.yaml.bak](..%2F..%2F..%2F..%2F..%2FUsers%2FAdministrator%2FDesktop%2F%D0%A1%D6%C7%CE%CA%CC%E2%2Frag-secret.yaml.bak)set_val, 
+    'sourcefile', sourcefile, 
+     'sourceline', sourceline 
+    )) FROM pg_settings;
+```
+利用规则提取和解析器结合专家知识,根据多配置依赖规则对配置项进行检测
+规则分为单节点和多节点,多节点使用rules_multi_node.csv,单节点使用rules_single_node.csv
+
+
+**修复方法：**
+
+修改postgresql.conf文件对应的配置项
+
 **参考来源：**
 无
\ No newline at end of file
-- 
Gitee