活动专区

活动公告

上车！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 这块资料时，一个感受越来越明显：很多团队其实不是没有日志，也不是没有审计，而是这些东西一开始开得很随意，后面又没人持续治理。结果往往很典型——要么出了问题找不到关键证据，要么日志越堆越多，最后先把磁盘吃紧；更麻烦一点的场景，是为了“查问题”一下子把审计和慢 SQL 跟踪全开，线上先被日志量和额外开销反过来拖慢。

我自己理解下来，GBase 8c 的日志、慢 SQL 跟踪、审计，这三块最好别混着看。它们都能帮助排障，但解决的是不同层面的问题：

- **运行日志** 更偏实例运行、异常、工具操作和故障定位。
- **慢 SQL / Full SQL 跟踪** 更偏性能观察和历史回溯。
- **审计日志** 更偏安全、对象操作、DML 行为和责任追踪。

真正落到现场时，我更关注的不是“要不要开”，而是下面这几个更实际的问题：

1. 现在到底要解决性能追踪，还是安全留痕。
2. 哪些项应该长期打开，哪些项只适合短期开。
3. 日志和审计文件怎么控量，避免查问题时把系统再拖慢一遍。

很多数据库现场最后变乱，不是因为没能力，而是因为没有把“采集、保留、查询、清理”当成一条完整链路去设计。

## 我一般先把日志类问题分成这几类

| 现场现象 | 我优先怀疑的点 | 第一动作 |
|---|---|---|
| 想查谁改了对象、谁做了 DML，但没有证据 | 审计项没提前开，或者开得不对 | 先看 `audit_enabled` 和具体审计项 |
| 慢 SQL 能感觉到，但历史不好追 | 慢 SQL 跟踪未开启或保留时间太短 | 看 `enable_stmt_track`、`log_min_duration_statement` |
| 节点磁盘突然变紧 | 审计/日志清理策略不完整 | 先看目录占用和保留参数 |
| 只知道系统慢，不知道慢在哪个时间段 | Full SQL / Slow SQL 没留够 | 先查 `dbe_perf` 视图和保留窗口 |
| 开了很多日志后系统反而更重 | 采集粒度过高、保留时间过长 | 先做分层治理，不要一把梭 |

从落地角度看，我更倾向于先把“性能日志”和“安全审计”拆开治理。因为这两类东西虽然都叫日志，但目标完全不一样。

## 一、先把这三类能力分清楚，不然后面很容易开错

我最近整理下来觉得，GBase 8c 现场里最容易混淆的，就是审计、慢 SQL 跟踪、普通运行日志。

### 1）运行日志更适合看实例和系统问题

GBase 8c 管理文档里把日志分成了系统日志、操作日志、Trace 日志、黑匣子日志、审计日志、WAL 日志、性能日志等几类。这个分类本身就很有用，因为它提醒我们：不是所有问题都要去翻同一种日志。系统运行异常、工具执行轨迹、性能外部资源访问、本来就不是一层问题。
我自己做排障时，如果是“节点异常、实例报错、工具改过参数、OM 操作历史”这类事，通常先看运行日志和工具日志，不会一上来先查审计。路径上也会先从实例运行目录、工具日志目录、性能日志目录这几类地方下手。部署方式不同目录会有差异，但按官方文档和社区常见场景，数据库节点运行日志、工具日志、性能日志、审计目录本身都是分层管理的。

### 2）慢 SQL 跟踪更适合做性能回看

慢日志这块，我个人更愿意把它理解成“性能观察窗”。它不一定帮你回答“谁干了这件事”，但很适合回答“什么时间开始慢、慢了多久、那段时间有哪些 SQL 最可疑”。

GBase 8c 社区里关于慢日志配置的内容已经把相关参数拆得很细了，比如：

- `enable_stmt_track`
- `track_stmt_stat_level`
- `log_min_duration_statement`
- `instr_unique_sql_count`
- `track_stmt_details_size`
- `track_stmt_retention_time`

这里我比较认同的一点是：**慢 SQL 跟踪不只是一个阈值参数，而是一整套采集粒度 + 记录数量 + 保留窗口的组合。**

### 3）审计更适合做责任留痕和行为回放

审计功能这块，GBase 8c 支持总开关和分项开关。也就是说，不是只有“开”和“关”两种粗粒度状态，而是可以按登录注销、对象操作、权限授予回收、DML、SELECT、函数执行、事务信息等项细分。
我自己理解下来，这就决定了审计不应该默认全量粗暴打开，而应该结合业务场景做有边界的配置。

## 二、我更习惯把日志治理拆成“长期常开”和“短期临时”两层

这个点我个人比较在意。很多团队一开始为了怕漏信息，把一堆能力全开，结果后面维护成本很高；还有一些团队相反，平时啥都不开，等出问题了再去补，最后发现关键窗口已经过去了。

所以我现在更倾向于这样拆：

| 层次 | 更适合长期常开 | 更适合短期开启 |
|---|---|---|
| 运行日志 | 实例日志、工具日志、基础告警相关日志 | Trace、黑匣子增强信息 |
| 慢 SQL 跟踪 | 温和阈值的慢 SQL 记录 | 全量 SQL、较细粒度跟踪 |
| 审计 | 登录注销、权限变更、关键对象操作 | 指定表 DML、SELECT 审计、指定用户全量审计 |

这种拆法的好处很实际：

- 平时就有基础证据，不至于完全盲排。
- 真遇到问题时，可以再把粒度临时加细。
- 不至于把审计和 Full SQL 长期开到过重。

## 三、审计这块，我通常不会上来就全开

GBase 8c 的审计相关参数里，我最常关注的是下面这些：

| 参数 | 我更关心它解决什么问题 | 我一般怎么理解 |
|---|---|---|
| `audit_enabled` | 审计总开关 | 先确认总开关是否生效 |
| `audit_login_logout` | 登录、退出留痕 | 建议长期保留 |
| `audit_database_process` | 数据库启动、停止、恢复、切换 | 运维排障价值高 |
| `audit_grant_revoke` | 授权和回收权限 | 权限变更必须能追 |
| `audit_system_object` | CREATE / ALTER / DROP 等对象操作 | 对象治理很关键 |
| `audit_dml_state` | 指定表 DML 审计 | 不建议无边界乱开 |
| `audit_dml_state_select` | SELECT 审计 | 更要控制范围 |
| `full_audit_users` | 指定用户全量审计 | 更适合短期定位 |
| `no_audit_client` | 不纳入审计的客户端/IP | 排除噪音用 |
| `audit_xid_info` | 在审计中记录事务信息 | 对串联事务排查有帮助 |

我自己更倾向于这样一套思路：

- **基础安全留痕长期保留**：登录注销、权限授予回收、数据库进程事件、关键对象变更。
- **业务行为审计按需打开**：某张表被误改、某个账号操作异常、某段时间需要追责，再开更细的 DML / SELECT。
- **指定用户全量审计只做短期定位**：别把它当常态。

### 一个我更常用的查看方式

先看总开关和关键分项：

```sql
show audit_enabled;
show audit_login_logout;
show audit_database_process;
show audit_grant_revoke;
show audit_system_object;
show audit_dml_state;
show audit_dml_state_select;
show full_audit_users;
show no_audit_client;
show audit_xid_info;
show audit_directory;
```

如果只是临时追某类对象变更，我一般会先做相对克制的配置，而不是全开：

```bash
gs_guc reload -N all -I all -c "audit_enabled = on"
gs_guc reload -N all -I all -c "audit_system_object = 67121159"
gs_guc reload -N all -I all -c "audit_grant_revoke = 1"
gs_guc reload -N all -I all -c "audit_dml_state = 1"
```

这里要特别注意一点：**开启 DML 或 SELECT 审计，不等于应该长期开着。**
真正落地时，这种参数更适合在明确目标对象、明确时间窗口的前提下使用。

## 四、慢 SQL 和 Full SQL 这块，最怕的不是没开，而是开得没边界

GBase 8c 社区对慢日志参数已经给过比较清楚的配置思路。我自己现在处理这块，通常先不纠结“要不要抓”，而是先问：

1. 抓的是慢 SQL，还是全量 SQL。
2. 只抓概况，还是要更细粒度。
3. 想保留多久。
4. 允许系统里累计多少 unique SQL 条目。

下面这几个参数，是我更常盯的：

| 参数 | 作用 | 我更在意的点 |
|---|---|---|
| `enable_stmt_track` | 是否启用 Full/Slow SQL 捕获 | 总开关，先看它 |
| `track_stmt_stat_level` | 控制全量和慢 SQL 跟踪级别 | 粒度不要无脑拉满 |
| `log_min_duration_statement` | 慢 SQL 阈值 | 先用能反映业务体感的阈值 |
| `instr_unique_sql_count` | unique SQL 条目数量控制 | 防止记录膨胀 |
| `track_stmt_details_size` | 单条 SQL 记录大小 | 超长 SQL 现场很重要 |
| `track_stmt_retention_time` | Full / Slow SQL 保留时间 | 直接关系追溯窗口 |

我自己更愿意用“分层采集”这个思路：

| 场景 | 我更倾向的配置 |
|---|---|
| 日常观察 | 开启慢 SQL 跟踪，阈值相对温和 |
| 问题复现窗口 | 保持慢 SQL，适度拉长保留时间 |
| 重大性能排障 | 临时打开 Full SQL 或更高粒度 |
| 业务高峰期 | 控制保留窗口和唯一 SQL 数量，别把采集本身变成负担 |

一个相对常见、也比较容易落地的配置示意可以写成这样：

```bash
gs_guc reload -Z coordinator -N all -I all -c "enable_stmt_track = ON"
gs_guc reload -Z coordinator -N all -I all -c "track_stmt_stat_level = 'OFF,L0'"
gs_guc reload -Z coordinator -N all -I all -c "log_min_duration_statement = 1000"
gs_guc reload -Z coordinator -N all -I all -c "instr_unique_sql_count = 200000"
gs_guc reload -Z coordinator -N all -I all -c "track_stmt_retention_time = '3600,10800'"
```

这里我自己有个习惯：
**先开慢 SQL，再决定要不要补 Full SQL。**
因为慢 SQL 主要解决“先找到嫌疑对象”，Full SQL 解决的是“把窗口里所有语句都捞出来看”。两个层次不一样，没必要长期混用。

## 五、查询手段也要分层，不然日志明明开了也不好用

光开参数还不够，真正落地时，能不能方便查出来更关键。

### 1）查审计记录

如果要回看某个时间段的审计动作，我一般先用：

```sql
select *
from pg_query_audit('2026-04-01 09:00:00','2026-04-01 11:00:00');
```

如果已经知道自己要找的是 DML 或对象操作，我通常会再加过滤条件，不然结果太散：

```sql
select time,
       username,
       database,
       type,
       result,
       detail_info
from pg_query_audit('2026-04-01 09:00:00','2026-04-01 11:00:00')
where type in ('dml_action', 'dml_action_select')
  and detail_info like '%orders_fact%';
```

### 2）查慢 SQL 和全量 SQL

这部分我更常用 `dbe_perf` 相关视图：

```sql
select *
from dbe_perf.get_global_slow_sql_by_timestamp(
  '2026-04-01 09:00:00'::timestamp with time zone,
  '2026-04-01 10:00:00'::timestamp with time zone
);
```

如果现场需要看某个窗口的完整 SQL 历史，再去查全量：

```sql
select *
from dbe_perf.get_global_full_sql_by_timestamp(
  '2026-04-01 09:00:00'::timestamp with time zone,
  '2026-04-01 09:10:00'::timestamp with time zone
);
```

### 3）查目录和文件占用

只靠数据库视图还不够。日志治理最后一定会回到 OS 层面，所以我排查时通常也会顺手看目录占用：

```bash
du -sh /var/log/gbase/gbase/pg_log
du -sh /var/log/gaussdb/gbase/pg_audit

find /var/log/gaussdb/gbase/pg_audit -type f | wc -l
ls -lh /var/log/gbase/gbase/pg_log | tail
```

如果是 `gs_om` 方式部署，审计日志目录在社区资料里有比较明确的说明；但我自己的建议是，不要死记路径，先 `show audit_directory`，再去落 OS 路径验证，这样更稳。

## 六、日志留得住不等于治理到位，真正麻烦的是控量

我最近整理这块内容时，越来越觉得“会开”和“会管”其实是两回事。很多现场不是不会开日志，而是不会做保留策略。

审计日志这块，社区文章里提到的几个参数我觉得特别实用：

| 参数 | 我更关注的点 | 默认值信息 |
|---|---|---|
| `audit_directory` | 审计文件存储目录 | 社区文中给出默认目录 |
| `audit_resource_policy` | 使用空间策略还是其他策略 | 默认是 `on` |
| `audit_space_limit` | 审计文件总空间上限 | `1GB` |
| `audit_file_remain_time` | 最小保留时间 | `90` |
| `audit_file_remain_threshold` | 最大文件数量上限 | `1048576` |

这个地方我个人更在意的不是“默认值是多少”，而是**默认值是否适合你现场**。
比如：

- 审计开得比较细，但磁盘本来就紧，那 `audit_space_limit` 就不能继续放默认思路。
- 现场合规要求高，需要更长留存期，那就不能只看空间，不看保留时间。
- 某些环境 SQL 特别碎，慢 SQL 与审计一起开，文件数量上涨会很快，这时文件数量阈值和清理频率就很关键。

### 我更习惯的一套治理思路

| 治理目标 | 更合适的动作 |
|---|---|
| 怕磁盘被打满 | 先收紧保留窗口和空间上限 |
| 怕事后追不回来 | 给关键项保留更长时间，不是所有项都一视同仁 |
| 怕日志太碎不好查 | 统一时间窗口、统一归档策略 |
| 怕线上受影响 | 临时增强采集，问题结束后回退 |

配套的归档动作，我一般会建议运维侧至少有这种最基础的脚本思路：

```bash
#!/bin/bash
set -e

AUDIT_DIR="/var/log/gaussdb/gbase/pg_audit"
ARCHIVE_DIR="/data/archive/pg_audit/$(date +%F)"

mkdir -p "${ARCHIVE_DIR}"

find "${AUDIT_DIR}" -type f -mtime +7 -name "*.log" -print0 | \
xargs -0 -I {} mv {} "${ARCHIVE_DIR}/"

tar -czf "${ARCHIVE_DIR}.tar.gz" -C "$(dirname "${ARCHIVE_DIR}")" "$(basename "${ARCHIVE_DIR}")"
```

这个脚本本身不复杂，但它能说明一个问题：
**日志治理最终一定会落回“清理、归档、保留、复查”这些运维动作上。**

## 七、我自己比较容易提醒团队的几个坑

### 1）把审计当成性能分析工具来用

审计能帮你追责和回放，但它不是纯粹的性能画像工具。性能问题优先看慢 SQL、Full SQL、执行计划和实例日志，别所有问题都先查审计。

### 2）把 SELECT 审计和 DML 审计长期粗暴打开

这类开关在定位问题时很好用，但长期无边界启用，代价通常不小。我更倾向于按表、按用户、按时间段使用。

### 3）只会开，不会收

很多现场出了问题先开一堆参数，问题过去了却不回退。过一阵子系统变重、磁盘变紧，又开始怀疑业务量。真正根因其实是采集策略没收回来。

### 4）只看数据库，不看 OS 层目录

数据库视图能帮你查记录，但磁盘占用、目录文件数、归档是否执行，还是要回到 OS 层检查。

### 5）把所有日志都留一样久

从治理角度看，这种做法最省事，但通常不是最优。登录注销、权限变更、对象变更、慢 SQL、全量 SQL，本来就不该完全同一套保留策略。

## 八、我现在更认可的一套落地顺序

如果让我现在给 GBase 8c 做一套更稳一点的日志与审计治理，我通常会按下面的顺序来：

1. **先定目标**
   是偏安全留痕，还是偏性能追踪，别混着开。
2. **再定长期常开项**
   登录注销、权限变更、关键对象操作、基础慢 SQL，优先做成长期能力。
3. **然后定短期增强项**
   指定表 DML、SELECT 审计、指定用户全量审计、Full SQL，更适合短期开启。
4. **再定保留和空间策略**
   空间上限、文件数量、最小保留时间、Full/Slow SQL 保留窗口，都要落具体值。
5. **最后补查询和归档动作**
   不只是“开了”，而是要能查、能归档、能回退、能复盘。

## 结尾收一下

我最近重新整理 GBase 8c 这块内容时，越来越觉得日志和审计这件事，最怕的不是没开，而是没有治理思路。平时全关，出事时全开，最后要么证据不够，要么系统又被采集本身拖慢，这两种情况我都见得不少。

从落地角度看，我个人更倾向于这样理解：

- **运行日志解决实例和系统问题；**
- **慢 SQL / Full SQL 解决性能回看问题；**
- **审计解决行为留痕和责任追踪问题；**
- **保留、清理、归档，决定这套东西最后能不能长期用得住。**

把这几层拆开以后，很多事情就没那么乱了。真正做得稳的环境，通常不是日志最多的环境，而是该留的留住、该收的收得回来、出了问题能在合理时间里把证据找出来的环境。

## 参考资料

```text
[1] 南大通用GBase 8c审计功能简述
https://www.gbase.cn/community/post/4410

[2] GBase 8c维护审计日志（一）
https://www.gbase.cn/community/post/1964

[3] GBase 8c慢日志启用和查询
https://www.gbase.cn/community/post/3985

[4] 如何查看8c执行过的系统sql
https://www.gbase.cn/community/post/5544

[5] 日志参考
https://www.gbase.cn/docs/gbase-8c/02%20%E7%AE%A1%E7%90%86%E5%91%98%E6%8C%87%E5%8D%97/03%20%E8%BF%90%E7%BB%B4%E7%AE%A1%E7%90%86/%E6%97%A5%E5%BF%97%E5%8F%82%E8%80%83

[6] 管理数据库安全
https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E7%AE%A1%E7%90%86%E6%95%B0%E6%8D%AE%E5%BA%93%E5%AE%89%E5%85%A8
```





GBase 8c

GBase 8c 审计和日志，别等磁盘打满了再回头补

GBase 8c 审计和日志，别等磁盘打满了再回头补

评论

热门帖子