活动专区

活动公告

上车！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 对象依赖与 DDL 变更风险排查

我最近看 GBase 8c 资料时，越来越强烈的一个感觉是：很多线上 DDL 变更出问题，并不是因为语法不会写，而是因为大家把注意力都放在“这条 ALTER 能不能执行”，却没把对象依赖、长事务、会话等待和发布窗口一起看。

真正落到现场时，DDL 风险往往不是一个点，而是一串连锁反应。表结构要改，业务代码已经依赖旧字段；字段类型刚改完，视图、函数、存储过程、触发器可能还引用旧定义；发布窗口里明明改动不大，但前面有长事务没结束，DDL 一拿锁就挂住，后面应用连接开始排队，现场看起来像“数据库突然卡了”。

我自己理解下来，GBase 8c 这类问题最难受的地方，不在于报错本身，而在于很多风险在变更前其实是可以提前看到的。只要把检查顺序理顺，DDL 上线这件事会比很多人想象中可控得多。

## 现场里最容易忽略的，不是 SQL 本身

我实际排查时一般先把 DDL 风险拆成四类：对象依赖、事务占用、锁等待、兼容行为差异。这样看问题会比直接盯着一条 ALTER TABLE 清晰很多。

| 风险点 | 现场常见表现 | 真正麻烦的地方 | 我更关注什么 |
|---|---|---|---|
| 对象依赖 | 改表后视图/函数报错 | 影响常常滞后出现，不一定在变更当下暴露 | 依赖对象有没有被完整找出来 |
| 长事务 | DDL 一直不返回 | 不是 DDL 慢，而是前面事务没结束 | 谁持有快照、谁占着事务不交 |
| 锁等待 | 应用请求堆积 | 看起来像性能问题，实际是发布窗口阻塞 | 等待链有没有继续扩散 |
| 兼容差异 | 测试环境正常，生产报语义问题 | 不同兼容模式下对象行为可能不同 | 兼容库、插件、对象定义是不是一致 |

很多团队把 DDL 变更当成“执行成功就算完成”，我个人更倾向于把它当成一类发布动作。也就是说，真正该管的不是命令有没有跑通，而是：跑之前有没有确认依赖，跑的时候有没有兜底，跑完之后有没有回看对象状态。

## 我自己常用的一套排查顺序

我最近整理下来觉得，GBase 8c 上 DDL 发布前，至少要做三层检查：先看依赖，再看会话和事务，最后才是执行窗口里的参数和操作方式。

### 1）先把依赖对象摸清楚

表结构一改，最容易受影响的通常不是表本身，而是围绕这张表建立起来的视图、函数、存储过程、触发器和部分应用侧动态 SQL。

我一般先从系统对象关系里把直接依赖捞出来，再结合业务对象做二次确认。下面这类查询在变更前非常有用，至少能先知道“谁可能被波及”。

```sql
-- 关注某张表被哪些对象依赖
SELECT
    n.nspname              AS schema_name,
    c.relname              AS object_name,
    c.relkind              AS object_type,
    d.deptype              AS dep_type
FROM pg_depend d
JOIN pg_class c
  ON d.objid = c.oid
JOIN pg_namespace n
  ON c.relnamespace = n.oid
WHERE d.refobjid = 'acct_core.trade_order'::regclass
ORDER BY 1,2;
```

如果我要改的是字段，不只是表级依赖，还会继续去看视图定义、函数定义和触发器逻辑里是否硬编码了字段名。表级依赖能帮我缩小范围，但还不够。

```sql
-- 看视图定义里是否引用了待变更字段
SELECT schemaname, viewname, definition
FROM pg_views
WHERE definition ILIKE '%trade_order%'
   OR definition ILIKE '%settle_status%';
```

```sql
-- 看函数/过程定义里是否引用了待变更字段
SELECT
    n.nspname AS schema_name,
    p.proname AS proc_name,
    pg_get_functiondef(p.oid) AS proc_def
FROM pg_proc p
JOIN pg_namespace n
  ON p.pronamespace = n.oid
WHERE pg_get_functiondef(p.oid) ILIKE '%trade_order%'
   OR pg_get_functiondef(p.oid) ILIKE '%settle_status%';
```

这里有个误区我见得比较多：有人觉得“改个列类型而已，应用 SQL 能跑就行”。但真到现场，很多问题不是应用 SQL 报出来的，而是某个报表视图、某段夜间调度过程、某个审计触发器先炸了。依赖没摸清时，DDL 风险其实是不可控的。

### 2）再看是不是有长事务占着窗口

我自己更关注的是：DDL 为什么迟迟拿不到执行机会。很多时候不是表太大，也不是系统太慢，而是发布前已经有会话把事务拉得很长，导致元数据变更拿锁困难。

下面这类查询我一般会在发布前和发布中都跑一遍：

```sql
-- 查活跃事务和会话持续时间
SELECT
    pid,
    usename,
    application_name,
    client_addr,
    state,
    xact_start,
    now() - xact_start AS xact_age,
    query_start,
    now() - query_start AS query_age,
    waiting,
    query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;
```

如果发现有事务已经挂了十几分钟甚至更久，我通常不会急着直接发 DDL，而是先确认这是不是业务侧忘提交、批处理长时间占用、连接池里留存事务，或者运维脚本把查询和人工确认放在同一事务里了。

| 检查项 | 我通常怎么判断 | 风险等级 |
|---|---|---|
| `xact_age` 很长 | 先确认是不是业务长事务或人工会话未提交 | 高 |
| `state='idle in transaction'` | 基本优先处理，这类最容易把发布窗口拖死 | 高 |
| `query_age` 长但 `xact_start` 为空 | 更像长查询，不一定直接挡 DDL | 中 |
| 同一应用名反复出现长事务 | 往往是连接池或框架事务边界有问题 | 高 |

### 3）最后才轮到 DDL 执行策略本身

我最近看资料时发现，GBase 8c 的 GUC 参数可按数据库、用户、会话等不同层级设置，这对发布窗口很有用。我的习惯不是在全局上乱调，而是优先把会话级兜底参数配好，让本次 DDL 有明确超时边界。

```sql
-- 仅在当前发布会话生效，避免长时间卡死
SET lockwait_timeout = '5s';
SET statement_timeout = '15min';
SET search_path = acct_core;
```

如果只是一次性发布，我更倾向于用会话级参数控制，而不是直接改全局配置。原因很简单：DDL 窗口的风险应该在窗口内收敛，不该把整套环境都拉进去陪跑。

有些变更还需要先把应用写流量收住，再执行 DDL，再做对象校验。我自己一般会把变更动作拆成“小步快跑”的方式，而不是在一个脚本里连着跑十几条高风险语句。

## 为什么同样是 DDL，有的改动风险高得多

DDL 不是只有“能改”和“不能改”两种状态。真正落到上线时，我更关注影响范围和回退难度。

| DDL 类型 | 典型语句 | 主要风险 | 我的建议 |
|---|---|---|---|
| 加字段 | `ALTER TABLE ... ADD COLUMN` | 低到中，主要看默认值和下游对象 | 先确认 ORM、ETL、导出程序是否依赖列顺序 |
| 改字段类型 | `ALTER TABLE ... ALTER COLUMN ... TYPE` | 高，最容易打到视图、函数和隐式转换 | 先做依赖扫描，再做灰度验证 |
| 改字段名 | `ALTER TABLE ... RENAME COLUMN` | 高，业务 SQL 和对象引用都可能失效 | 能兼容过渡就别一步重命名 |
| 删除字段 | `ALTER TABLE ... DROP COLUMN` | 很高，失败点最多 | 优先走“停用字段 -> 清依赖 -> 再删除” |
| 改默认值/约束 | `ALTER TABLE ... ALTER COLUMN SET DEFAULT` | 中，影响新增数据行为 | 要和应用默认值逻辑一起看 |

我个人更倾向于把高风险变更拆成两次发布。比如字段重命名，不要一步到位。很多现场更稳妥的做法是先加新字段、应用双写、观察、切换读取、清理依赖，最后再下掉旧字段。这样会比一次性 DDL 漂亮得多，也更符合线上系统的容错节奏。

## 我会怎么做发布前检查

下面这段 Shell 我自己觉得很实用，虽然不复杂，但能把“对象依赖 + 长事务 + 当前连接”这三块快速扫一遍。上线窗口前跑一次，很多坑能提前暴露出来。

```bash
#!/bin/bash
DB=paydb
PORT=15432
USER=gbase

SQL1="
SELECT now() AS check_time,
       pid, usename, application_name, state,
       now()-xact_start AS xact_age,
       waiting
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;
"

SQL2="
SELECT schemaname, viewname
FROM pg_views
WHERE definition ILIKE '%trade_order%'
   OR definition ILIKE '%settle_status%';
"

gsql -d ${DB} -p ${PORT} -U ${USER} -c "${SQL1}"
gsql -d ${DB} -p ${PORT} -U ${USER} -c "${SQL2}"
```

如果发布内容比较多，我还会把待变更对象、依赖对象、执行顺序、回退语句单独放成一个清单，不让 DDL 现场靠人工记忆。

## 变更脚本怎么写，我自己更倾向于保守一点

如果确实要批量执行 DDL，我一般不会上来就写一坨无保护脚本直接跑，而是会加最基本的检查和日志输出。特别是涉及 schema 级批量对象变更时，动态 SQL 很方便，但越方便越要克制。

```sql
DO $$
DECLARE
    v_exists INTEGER;
BEGIN
    SELECT COUNT(*)
      INTO v_exists
      FROM information_schema.columns
     WHERE table_schema = 'acct_core'
       AND table_name   = 'trade_order'
       AND column_name  = 'settle_status';

    IF v_exists = 1 THEN
        EXECUTE 'ALTER TABLE acct_core.trade_order ALTER COLUMN settle_status TYPE VARCHAR2(32)';
    END IF;
END;
$$;
```

这类写法的价值不在“炫技巧”，而在于把脚本做成可重入、可判断、可留痕。真正在现场里，脚本第二次执行是否安全，往往比第一次执行是否优雅更重要。

## 我自己会盯的几个关键参数和动作

GBase 8c 的参数设置方式比较灵活，我自己更关注会话级和数据库级两层。发布窗口里，不少问题不是内核不支持，而是参数粒度用错了。

| 项目 | 作用 | 更适合放在哪一层 | 注意点 |
|---|---|---|---|
| `lockwait_timeout` | 控制锁等待上限 | 会话级 | 适合发布窗口兜底，别轻易全局改 |
| `statement_timeout` | 控制语句最长执行时间 | 会话级/用户级 | 防止脚本卡住不返回 |
| `search_path` | 控制对象解析路径 | 会话级 | 发布脚本里最好显式指定 |
| `ALTER SYSTEM SET` | 改系统层参数 | 系统级 | 不适合临时发布兜底 |
| `gs_guc reload/set` | 改运行参数 | 集群级 | 要区分是否需要重启和影响范围 |

如果发布前已经确认存在明显长事务，我个人更倾向于先处理事务源头，而不是靠放大超时去硬等。等出来的 DDL 成功，很多时候只是把后面的业务抖动延后了。

## 现场里几个很容易踩的坑

### 1）只校验表，不校验外围对象

这类问题最常见。表改完能查，大家就以为没事了。结果第二天定时报表失败，或者某个过程在夜间批处理时报字段不存在。根因通常不是数据库突然出问题，而是依赖清单没做完。

### 2）把测试环境结果直接等同于生产

我自己更关注的是对象定义和兼容模式是否一致。尤其是涉及兼容库、插件、函数行为差异时，测试环境能过，不代表生产环境对象链路也一样。环境差异不一定体现在版本号上，也可能体现在 schema、插件加载状态、搜索路径和权限边界上。

### 3）一个发布脚本里塞太多高风险动作

真正落到现场时，最怕的不是一条语句失败，而是失败以后不知道已经执行到哪一步。DDL 脚本过长、对象跨 schema、还夹杂数据修复语句时，回退会非常痛苦。

### 4）把等待误判成性能问题

这也是我最近排查里感受很深的一点。发布窗口里应用响应慢，不一定是 CPU 打满、IO 高、执行计划变差，有时只是 DDL 前后锁等待扩散了。这个阶段如果只盯系统资源，很容易把方向查偏。

## 我自己的发布建议

我最近整理下来觉得，GBase 8c 上做 DDL 变更，顺序比技巧重要。

1. 先确认待变更对象和影响范围，不要只看表。
2. 再扫长事务和会话状态，不要带着阻塞去发 DDL。
3. 发布会话显式设置超时、schema 路径和日志输出。
4. 高风险动作尽量拆批，避免大脚本一次跑完。
5. 变更后立即校验视图、函数、过程和关键业务 SQL。

如果只能记住一件事，我自己更愿意记这句：**GBase 8c 的 DDL 风险，很多时候不是“改不改得动”，而是“改动之后，谁会被连带影响”。** 把这件事想明白，很多线上结构变更就不会再靠运气。

## 结尾

我最近看资料和整理现场问题时，越来越觉得 GBase 8c 的 DDL 变更不适合只从语法层面理解。真正稳定的做法，还是把依赖、事务、锁等待、参数边界和发布动作放在一起看。

从落地角度看，DDL 变更越是看起来简单，越值得提前把外围对象和执行窗口查清楚。因为线上真正让人被动的，往往不是那条 ALTER TABLE，而是那条 ALTER TABLE 背后没被看到的依赖链。

```text
参考资料

[1] GBase 8c 文档介绍
https://www.gbase.cn/docs/gbase-8c/%E6%AC%A2%E8%BF%8E/

[2] 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

[3] 数据库使用
https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E6%95%B0%E6%8D%AE%E5%BA%93%E4%BD%BF%E7%94%A8

[4] 存储过程
https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E5%AD%98%E5%82%A8%E8%BF%87%E7%A8%8B

[5] GBase 8c 开发者手册
https://cdn.gbase.cn/products/34/Pr3MGDrcOeeWwC9kdNEjM/GBase%208c%20V5_3.0.1_%E5%BC%80%E5%8F%91%E8%80%85%E6%89%8B%E5%86%8C_V1.1_20240119.pdf

```



GBase 8c

GBase 8c 对象依赖与 DDL 变更风险排查

GBase 8c 对象依赖与 DDL 变更风险排查

评论

热门帖子