活动专区

活动公告

上车！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 资料时，一个感受越来越明显：很多表结构变更失败，并不是 DDL 语法本身有问题，而是变更前没有把对象依赖和影响面查清楚。

现场里很常见的一类情况是：测试库里 `ALTER TABLE` 很顺，到了生产库却突然报依赖错误，或者虽然语句执行成功了，但后面的视图、触发器、过程、报表任务开始连锁异常。再往后查，往往不是数据库“脾气古怪”，而是对象之间本来就有引用关系，只是平时没把这张依赖网摊开看。

我自己理解下来，GBase 8c 的表结构变更，真正难的不是把 DDL 写出来，而是回答下面这几个问题：

- 这个表现在被哪些对象引用了。
- 这些引用是“能独立删”的，还是“跟着宿主一起删”的。
- 这次变更是纯元数据动作，还是会引发表重写、空间占用和更长窗口期。
- catalog 里能查到的依赖，和业务代码里手写的动态 SQL，分别要怎么确认。

所以我现在做 8c 结构变更，基本都会先做一轮“对象依赖体检”，再决定到底是直接改、分阶段改，还是新旧对象并行切换。

## 先把风险分层，不要一上来就执行 DDL

我最近整理下来觉得，表结构变更至少可以分成下面几类，处理思路完全不一样。

| 变更动作 | 现场最容易踩的点 | 我更倾向的处理方式 |
| --- | --- | --- |
| 新增列 | 看起来简单，但默认值、非空约束可能触发额外扫描或重写 | 先加可空列，再分批回填，再补约束 |
| 删除列 | 依赖视图、规则、过程；删得快但空间不会立刻回来 | 先查依赖，再确认是否真要马上删 |
| 修改列类型 | 可能重写整表，窗口期和磁盘占用都要重估 | 热表优先走“新列替换” |
| 重命名表/列 | 业务 SQL、存储过程、外部任务脚本容易漏改 | 先扫数据库对象，再扫应用脚本 |
| 删除表 | 影响范围最大，`CASCADE` 一旦用错很难止损 | 先把依赖对象列清楚，尽量不用盲删 |

我实际排查时一般先看两件事：

1. 这次变更会不会触发表重写。
2. 这张表上游下游挂了多少对象。

原因很简单。前者决定变更窗口，后者决定回滚难度。

## 我会先看的几个系统对象

GBase 8c 的好处是，很多对象关系并不是“黑盒”，系统表和系统视图里能看到相当多线索。我自己更关注下面这几组。

| 排查入口 | 主要用途 | 我通常怎么看 |
| --- | --- | --- |
| `PG_TABLES` | 看表是否有触发器、创建时间、最后 DDL 时间 | 先确认对象近期有没有被改过 |
| `PG_OBJECT` | 看对象创建人与修改时间 | 判断对象最近是否被二次加工过 |
| `PG_DEPEND` | 看依赖链的核心入口 | 判断是普通依赖、自动依赖还是内部依赖 |
| `PG_REWRITE` | 视图/规则类依赖的重要线索 | 查视图对基表的引用不能只看名字 |
| `PG_VIEWS` | 查视图定义 | 快速做定义级确认 |
| `PG_TRIGGER` | 查表上的触发器、触发函数、是否启用 | 结构改动前必须过一遍 |
| `PG_PROC` | 查函数/过程定义、参数和源码线索 | 动态 SQL 场景我会二次扫源码 |

其中我最近最常用的是 `PG_DEPEND`、`PG_OBJECT` 和 `PG_VIEWS` 这一组。

- `PG_DEPEND` 适合做“谁依赖谁”的主干排查。
- `PG_OBJECT` 适合补“这个对象最近有没有被改过”。
- `PG_VIEWS` 和 `PG_TRIGGER` 适合把定义内容补齐，避免只看到对象名，看不到真实影响。

## 先确认对象状态，再决定要不要进维护窗口

我通常不会一上来就跑改表语句，而是先把对象元数据和最近 DDL 情况看一遍。

```sql
SELECT schemaname,
       tablename,
       tableowner,
       hasindexes,
       hasrules,
       hastriggers,
       created,
       last_ddl_time
FROM pg_tables
WHERE schemaname = 'acct'
  AND tablename  = 'txn_order';
```

如果还想把对象级信息补全，我会再看一次 `PG_OBJECT`。

```sql
SELECT object_oid,
       object_type,
       creator,
       ctime,
       mtime,
       changecsn
FROM pg_object
WHERE object_oid = 'acct.txn_order'::regclass;
```

我自己更关注的是 `last_ddl_time` 和 `mtime`。因为不少现场问题不是“这张表一直没动”，而是最近有人做过授权、改过索引、调过表定义，只是变更单里没写出来。这个时候如果直接套旧方案，很容易误判窗口大小。

## 查视图依赖时，我不会只看 PG_VIEWS

很多人排查表结构影响面，只会跑一句：

```sql
SELECT schemaname, viewname
FROM pg_views
WHERE definition ILIKE '%txn_order%';
```

这句有用，但我自己不会只停在这里。

原因是视图在系统里对应的不只是一个名字，还牵涉到重写规则。GBase 8c 的 `PG_REWRITE` 专门存这类规则信息，真正做依赖定位时，我更习惯把 `PG_REWRITE` 和 `PG_DEPEND` 一起看。

```sql
SELECT n.nspname      AS dep_schema,
       c.relname      AS dep_view,
       r.rulename     AS rule_name,
       d.deptype
FROM pg_depend d
JOIN pg_rewrite r
  ON r.oid = d.objid
JOIN pg_class c
  ON c.oid = r.ev_class
JOIN pg_namespace n
  ON n.oid = c.relnamespace
WHERE d.classid    = 'pg_rewrite'::regclass
  AND d.refclassid = 'pg_class'::regclass
  AND d.refobjid   = 'acct.txn_order'::regclass
ORDER BY 1, 2;
```

如果这里已经能查到多个依赖视图，我一般不会再考虑“直接删列”或者“直接改类型”这种一步到位的做法，而是优先改成分阶段方案。

## 触发器和过程是我更担心的隐性风险点

对业务表来说，触发器经常比视图更容易被漏掉。因为视图通常还能在对象清单里看见，触发器往往是表侧逻辑，平时不查就没存在感。

我一般会先看这张表上挂了哪些触发器、触发函数是谁、当前是不是启用状态。

```sql
SELECT n.nspname        AS schema_name,
       c.relname        AS table_name,
       t.tgname         AS trigger_name,
       p.proname        AS trigger_func,
       t.tgenabled,
       t.tgisinternal
FROM pg_trigger t
JOIN pg_class c
  ON c.oid = t.tgrelid
JOIN pg_namespace n
  ON n.oid = c.relnamespace
JOIN pg_proc p
  ON p.oid = t.tgfoid
WHERE n.nspname = 'acct'
  AND c.relname = 'txn_order'
ORDER BY t.tgname;
```

如果表结构改动涉及到触发器里使用的列名，我会继续向下看函数或过程定义。

```sql
SELECT n.nspname,
       p.proname,
       p.prokind,
       p.prosrc,
       p.proargsrc
FROM pg_proc p
JOIN pg_namespace n
  ON n.oid = p.pronamespace
WHERE p.prosrc ILIKE '%txn_order%'
   OR COALESCE(p.proargsrc, '') ILIKE '%txn_order%'
ORDER BY 1, 2;
```

这里我会特别小心一个问题：catalog 能查到的是非常重要的一层，但我不会把它当成全部结果。真正落到现场时，过程里拼动态 SQL、调包内私有函数、或者脚本侧直接拼列名，这些都可能绕开“显式依赖”的主链，所以最后我通常还会补一次源码检索和应用侧检索。

## 我最常拿来判断风险等级的是 deptype

`PG_DEPEND` 里最值得看的字段之一就是 `deptype`。我最近整理下来，做结构变更时可以把它先粗分成下面几类。

| deptype | 含义 | 我对它的理解 |
| --- | --- | --- |
| `n` | 普通依赖 | 被引用对象通常要配合 `CASCADE` 才能删除，最常见 |
| `a` | 自动依赖 | 宿主删掉时，这类对象通常会自动跟着处理 |
| `i` | 内部依赖 | 往往是内部实现的一部分，不能按普通对象随便单删 |
| `e` | extension 依赖 | 和扩展对象绑定，处理方式要按扩展边界来 |
| `p` | pin 依赖 | 系统自身依赖，不能碰 |

我个人更倾向于把 `n` 看成“上线前必须人工确认”的一类，把 `i` 和 `p` 看成“不要在生产直接试”的一类。因为这两种一旦误判，问题通常不是一条 SQL 回滚那么简单。

## 改列类型时，我通常优先评估“重写整表”的代价

这也是我最近特别在意的一点。很多人觉得改类型只是 DDL，应该很快，但 GBase 8c 的手册里其实把风险写得很明确：

- 改字段类型可能重写整个表。
- 用非空默认值加列，也可能重写整个表。
- 大表场景下，这类操作不仅时间长，还可能临时需要更多磁盘空间。

所以我的经验是：

| 场景 | 直接 `ALTER COLUMN TYPE` | 新列替换方案 |
| --- | --- | --- |
| 小表、低峰时段 | 可以考虑 | 不一定必须 |
| 热表、长事务多 | 风险偏高 | 更稳妥 |
| 有多个视图/过程依赖 | 不建议硬改 | 更容易做灰度切换 |
| 回滚要求严格 | 回滚路径不够直观 | 新旧列并行更好退回 |

我自己更偏向下面这种做法：

1. 新增目标类型的新列。
2. 分批回填。
3. 先改视图、过程、报表口径。
4. 观察一段时间。
5. 最后再处理旧列。

示意 SQL 可以像这样写：

```sql
ALTER TABLE acct.txn_order
  ADD COLUMN settle_ts_new timestamp;

UPDATE acct.txn_order
   SET settle_ts_new = to_timestamp(settle_ts_old, 'YYYY-MM-DD HH24:MI:SS')
 WHERE settle_ts_old IS NOT NULL
   AND settle_ts_new IS NULL;

CREATE OR REPLACE VIEW rpt.v_order_day AS
SELECT order_id,
       settle_ts_new AS settle_ts,
       amount,
       status_code
FROM acct.txn_order;
```

这种方式看起来多走了几步，但从落地角度看，最大的好处是把“高风险瞬时变更”拆成了“可观察、可回退的多步变更”。

## 我会把预检查结果直接落盘，不靠临场记忆

如果是正式变更，我一般会在 gsql 里把预检查结果直接导出来，避免窗口里来回复制。

```bash
gsql -d finance_core -h 192.0.2.31 -p 5432 -U app_dba &lt;&lt;'SQL'
\o ddl_precheck_txn_order_20260402.log
SELECT now();

SELECT schemaname, tablename, hastriggers, created, last_ddl_time
FROM pg_tables
WHERE schemaname = 'acct'
  AND tablename  = 'txn_order';

SELECT n.nspname, c.relname, r.rulename, d.deptype
FROM pg_depend d
JOIN pg_rewrite r ON r.oid = d.objid
JOIN pg_class c   ON c.oid = r.ev_class
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE d.classid    = 'pg_rewrite'::regclass
  AND d.refclassid = 'pg_class'::regclass
  AND d.refobjid   = 'acct.txn_order'::regclass
ORDER BY 1,2;

SELECT n.nspname, c.relname, t.tgname, p.proname, t.tgenabled
FROM pg_trigger t
JOIN pg_class c ON c.oid = t.tgrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_proc p ON p.oid = t.tgfoid
WHERE n.nspname = 'acct'
  AND c.relname = 'txn_order'
ORDER BY t.tgname;
\o
SQL
```

我最近养成这个习惯以后，变更复盘会轻松很多。至少出了问题时，能马上回到“变更前到底查到了什么”这个基线，而不是靠口头回忆。

## 现场里最容易忽略的几个坑

我自己踩过或者见过的坑，主要集中在下面几类。

| 常见坑 | 现场表现 | 我现在的处理习惯 |
| --- | --- | --- |
| 只查视图名，不查定义 | 以为没影响，实际口径已被引用 | `PG_VIEWS.definition` 必查 |
| 只查表，不查触发器 | 变更后写入链路异常 | 表级触发器固定纳入检查项 |
| 看到 `DROP COLUMN` 很快就直接执行 | 列逻辑消失了，但空间没马上回来 | 先分清“逻辑删除列”和“物理空间回收” |
| 直接 `CASCADE` | 一次删掉整串对象 | 先把依赖清单落盘，再决定是否级联 |
| 只看数据库对象，不看外部脚本 | 数据库没报错，任务调度开始失败 | 应用 SQL、ETL、报表脚本一起搜 |

这里我再多说一句。`DROP COLUMN` 在手册里的描述其实很关键：它快，并不代表没有后续影响。很多时候只是让这个列对 SQL 不再可见，空间并不会立刻以我们直觉里的方式回到系统里。所以结构变更和空间治理，最好不要混成一个动作去理解。

## 我现在更愿意用“先摸清依赖，再设计路径”的方式做 8c 变更

我最近整理这一块资料时，最大的变化不是学会了多少条 DDL，而是把思路改了。

以前更容易把结构变更理解成“执行一条 ALTER TABLE”。现在我更倾向于把它理解成三段：

- 先识别对象关系。
- 再评估这次变更是元数据动作还是重写动作。
- 最后才是选哪种实施路径。

对 GBase 8c 来说，`PG_DEPEND`、`PG_OBJECT`、`PG_REWRITE`、`PG_VIEWS`、`PG_TRIGGER` 这些系统对象已经给了我们很好的排查抓手。只要前面这轮检查做扎实，很多原本会在生产窗口里暴露的问题，其实在变更前就能看出七八成。

我自己现在做表结构改动，最不愿意看到的不是“语法报错”，而是“语法没报错，但依赖对象悄悄坏了”。前者还算早发现，后者往往才是最费时间的。

## 参考资料

```text
[1] GBase 8c 开发者手册 V5_3.0.1

[2] GBase 8c SQL 参考手册 V5_3.0.0

[3] GBase 8c 工具与命令参考手册 V5_5.0.0
```





GBase 8c

运维管理

GBase 8c 表结构变更前的对象依赖排查

GBase 8c 表结构变更前的对象依赖排查

评论

热门帖子