活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# GBase 8c 参数生效范围排查记录

我最近看 GBase 8c 资料时，对 GUC 参数这一块关注得比较多。以前处理参数问题时，我容易把注意力放在“参数值调大还是调小”上，后来在现场复盘里发现，很多问题并不是参数值本身不合理，而是参数根本没有在预期范围内生效。

这类问题的表现不算复杂：同一个 SQL，在一个用户下表现正常，换一个业务用户后行为不同；在读写 CN 上查到参数已经改了，但应用连接重新上来以后还是旧值；某个参数用 `gs_guc reload` 改过，结果发现必须重启才真正生效。真正落到现场时，如果一上来就讨论“这个参数该设多少”，很容易把排查方向带偏。我自己更关注的是先确认三件事：参数属于哪一类、通过哪种方式设置、当前会话最终拿到的是哪个值。

## 现场现象不是“参数没改”，而是“改到了别的层级”

我遇到过一个比较典型的情况：测试环境里为了方便观察执行计划，把 `explain_perf_mode` 调成了更详细的输出模式。DBA 在 CN 节点上确认 `SHOW explain_perf_mode;` 能看到目标值，但应用用户重新登录后拿到的结果和预期不一致。后来继续查才发现，这个用户之前单独设置过用户级参数，会话优先读到了用户级配置，而不是实例配置。

GBase 8c 的参数并不是只有一个配置文件入口。它可以通过配置文件、`gs_guc`、`ALTER SYSTEM`、`ALTER DATABASE`、`ALTER USER`、`SET` 等方式影响最终行为。这个设计很灵活，但也意味着排查时不能只看一个地方。

从落地角度看，我一般先把参数问题拆成下面几个判断：

| 判断点 | 我会先看什么 | 常见误判 | 处理思路 |
|---|---|---|---|
| 参数分类 | `pg_settings.context` | 以为所有参数 reload 都能生效 | 先确认是否需要重启、重新连接或仅当前会话有效 |
| 参数来源 | `source`、配置文件、ALTER 记录 | 只看 `SHOW`，不看来源 | 把实例级、库级、用户级、会话级分开 |
| 生效对象 | CN、DN、所有实例还是某个会话 | 只在一个节点确认成功 | 按实际访问路径逐个验证 |
| 连接生命周期 | 当前会话、新会话、重启后 | 修改后立刻用旧连接验证 | 新建连接后再确认一次 |
| 覆盖关系 | 会话级、用户级、库级、系统级 | 低层级修改被高优先级覆盖 | 找到最高优先级的设置点再处理 |

我自己理解下来，参数治理最怕“经验式确认”。只看到一处值正确，并不能说明业务实际使用的参数也正确。

## 参数分类先看 context，不要直接改

GBase 8c 的 GUC 参数有不同分类，例如 `INTERNAL`、`POSTMASTER`、`SIGHUP`、`BACKEND`、`SUSET`、`USERSET`。这些分类决定了参数能不能改、谁能改、什么时候生效。真正排查时，我不会先去翻配置文件，而是先在库里把参数元信息查出来。

```sql
-- 连接读写 CN 后查看参数元信息
SELECT name,
       setting,
       unit,
       context,
       source,
       pending_restart
  FROM pg_settings
 WHERE name IN ('work_mem',
                'statement_timeout',
                'explain_perf_mode',
                'authentication_timeout',
                'archive_mode')
 ORDER BY name;
```

这里我会重点看 `context` 和 `pending_restart`。如果 `pending_restart` 为 true，说明当前看到的配置调整还没有通过重启真正落到运行态。这个字段在排查“配置文件里明明改了，为什么业务没变化”时很有用。

| context 类型 | 我的理解 | 生效特点 | 排查重点 |
|---|---|---|---|
| INTERNAL | 初始化或内部固定参数 | 不能按普通方式修改 | 不要在现场临时调整 |
| POSTMASTER | 服务启动时确定 | 通常需要重启 | 看配置是否已写入、是否已重启 |
| SIGHUP | 全局参数 | reload 后生效，可能有延迟 | 看 reload 是否执行到目标节点 |
| BACKEND | 建立连接时确定 | 新连接生效 | 旧连接不会自动变化 |
| SUSET | 管理员可设置 | 可在多个层级设置 | 看是否被用户级或库级覆盖 |
| USERSET | 普通用户可设置 | 会话级最灵活 | 看应用是否显式 SET |

这张表不是为了背参数分类，而是为了确定排查动作。比如 `POSTMASTER` 类型参数，如果还在旧连接里反复 `SHOW`，意义并不大；`BACKEND` 类型参数，修改后不重新建立连接，也很容易误判。

## 设置方式要和生效目标匹配

GBase 8c 里常见的参数设置方式大概可以分成四类。现场容易出问题的不是命令不会写，而是设置方式和生效目标不匹配。

```bash
# 示例：实例级设置，通常配合重启或 reload 使用
gs_guc set -N all -I all -c "archive_mode=off"

# 示例：reload 方式调整 SIGHUP 类型参数
gs_guc reload -N all -I all -c "authentication_timeout=59s"

# 重启集群时要结合实际 dcslist 路径
gha_ctl restart all -l /home/gbase/cluster/dcslist
```

SQL 层也能设置参数：

```sql
-- 数据库级，通常新会话生效
ALTER DATABASE app_dw SET statement_timeout TO '300s';

-- 用户级，通常新会话生效
ALTER USER rpt_reader SET work_mem TO '128MB';

-- 会话级，只影响当前连接
SET statement_timeout TO '120s';

-- 查看当前会话最终值
SHOW statement_timeout;
SHOW work_mem;
```

从处理顺序看，我个人更倾向于先确认“这个参数应该控制谁”：如果是整个集群的行为，就不要只在某个用户上 `ALTER USER`；如果只是某个报表用户需要更大内存，就不要把全局参数调得很激进；如果只是临时排查，`SET` 会话级就够了，避免把试验配置留在系统里。

| 设置方式 | 适合场景 | 风险点 | 我会怎么验证 |
|---|---|---|---|
| `gs_guc set` | 需要写配置并重启的参数 | 影响面大，窗口要求高 | 查配置文件、重启后查 `pg_settings` |
| `gs_guc reload` | SIGHUP 类参数 | 节点范围没覆盖全 | 多节点验证，必要时看配置文件 |
| `ALTER SYSTEM` | SQL 方式管理实例级参数 | 忽略参数 context | 查 `pending_restart` 和实际值 |
| `ALTER DATABASE` | 某个库默认行为 | 跨库行为不一致 | 用目标库新建连接验证 |
| `ALTER USER` | 某类业务用户差异化配置 | 覆盖全局期望 | 用目标用户新建连接验证 |
| `SET` | 当前会话临时调试 | 退出即失效 | 只作为临时排查手段 |

## 优先级问题最容易被忽略

我实际排查时，一旦发现“DBA 查到一个值，应用表现像另一个值”，会直接怀疑覆盖关系。GBase 8c 参数设置存在优先级。会话级 `SET` 通常最直接，其次要看数据库级、用户级设置，再往下才是系统级设置。

一个比较实用的排查方式是用同一个参数分别在不同用户、不同数据库下验证。

```sql
-- 用管理员查看是否存在库级、用户级设置
SELECT datname, datconfig
  FROM pg_database
 WHERE datconfig IS NOT NULL;

SELECT rolname, rolconfig
  FROM pg_roles
 WHERE rolconfig IS NOT NULL;

-- 切换到目标业务库、目标业务用户后确认
SHOW statement_timeout;
SHOW work_mem;
```

如果业务侧连接池在初始化时执行了 `SET statement_timeout`，数据库侧全局设置再怎么改，也可能被应用连接初始化逻辑覆盖。这个问题很隐蔽，因为 DBA 在命令行里验证完全正常，只有应用连接表现异常。

我最近整理下来觉得，参数排查不能只停在数据库内部，还要把连接池初始化 SQL 纳入范围。尤其是 Java 应用、报表工具、数据服务平台，有些会在连接创建后自动设置超时、字符集、搜索路径、执行模式等参数。

## 一个参数调整前后的记录模板

为了避免口头沟通造成混乱，我现在更倾向于把参数调整做成一张小记录。不是为了形式，而是为了后续能复盘清楚。

```sql
-- 调整前记录
SELECT now() AS check_time,
       name,
       setting,
       unit,
       context,
       source,
       pending_restart
  FROM pg_settings
 WHERE name = 'statement_timeout';

-- 会话级验证
SET statement_timeout TO '180s';
SHOW statement_timeout;

-- 恢复会话级设置
RESET statement_timeout;
SHOW statement_timeout;
```

参数调整记录建议至少包含这些字段：

| 字段 | 示例 | 为什么要记 |
|---|---|---|
| 参数名 | `statement_timeout` | 后续复盘定位 |
| 原值 | `0` | 判断调整幅度 |
| 新值 | `180s` | 明确变更结果 |
| 设置层级 | 用户级 / 库级 / 系统级 | 避免覆盖关系说不清 |
| 生效方式 | 当前会话 / 新连接 / reload / restart | 决定验证动作 |
| 影响对象 | `rpt_reader@app_dw` | 避免全局误伤 |
| 回退命令 | `ALTER USER ... RESET` | 出问题时能快速恢复 |

对应的回退命令也要提前准备好：

```sql
-- 回退数据库级参数
ALTER DATABASE app_dw RESET statement_timeout;

-- 回退用户级参数
ALTER USER rpt_reader RESET work_mem;

-- 回退当前会话
RESET statement_timeout;
RESET work_mem;
```

真正落到现场时，参数不是调完就结束。能不能回退、回退后怎么验证，往往比调参动作本身更关键。

## 常见坑

| 常见坑 | 现场表现 | 我的处理方式 |
|---|---|---|
| 用旧连接验证新参数 | `SHOW` 结果一直不变 | 断开后重新连接 |
| 只在一个 CN 验证 | 应用访问另一个 CN 后行为不同 | 按访问入口逐个确认 |
| 忽略用户级配置 | 管理员看到正常，业务用户异常 | 查 `pg_roles.rolconfig` |
| 忽略库级配置 | 换库后参数变化 | 查 `pg_database.datconfig` |
| 把临时 SET 当成永久变更 | 会话断开后失效 | 明确记录设置层级 |
| 参数单位没写清 | 内存或时间值偏离预期 | 查 `pg_settings.unit` |
| 修改 POSTMASTER 参数不重启 | 配置已写入但运行不生效 | 看 `pending_restart` |

我个人更倾向于把参数问题看成“配置链路排查”，而不是单纯调大调小。尤其在 GBase 8c 分布式环境里，节点、用户、库、会话这些层级叠在一起，先把链路理顺，后面才有讨论参数值的基础。

## 结尾总结

GBase 8c 的 GUC 参数管理很灵活，但灵活也带来了排查复杂度。我的经验是不要一开始就争论参数值，而是先确认参数分类、生效方式、设置层级和覆盖关系。很多现场问题并不是参数不支持，也不是命令写错，而是参数被设置在了不合适的位置，或者验证时没有站在业务实际连接的角度看。

从落地角度看，我会把参数调整拆成四步：先查 `pg_settings`，再确认设置来源，然后用目标用户和目标库新建连接验证，最后保留回退命令。这样处理虽然慢一点，但能明显减少“改了以后说不清”的风险。

## 参考资料

```text
[1] GBase 8c GUC参数说明 https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/GUC%E8%BF%90%E8%A1%8C%E5%8F%82%E6%95%B0
[2] GBase 8c 文档介绍 https://www.gbase.cn/docs/gbase-8c/%E6%AC%A2%E8%BF%8E/
[3] GBase 社区优质文章区 https://www.gbase.cn/community/section/11
```





GBase 8c

运维管理

GBase 8c 参数生效范围排查记录

GBase 8c 参数生效范围排查记录

评论

热门帖子