任务第一次失败不可怕，要吸取教训。

活动专区

活动公告

上车！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 8a 会话残留和作业重跑时的上下文污染

我最近看资料和整理重跑失败案例时，越来越觉得 GBase 8a 里很多“手工补跑没问题，系统重跑却不稳定”的问题，不一定是 SQL 逻辑差，也不一定是对象本身坏了，更常见的是**会话残留、上下文复用和中间状态没有清干净**。

现场里经常会看到这种情况：
同一批任务第一次失败，第二次重跑结果又变了；同一个脚本手工执行没事，调度系统重试后却报对象已存在、变量残留或者环境不一致；还有一些更隐蔽，会话级设置、临时对象、错误中断后的上下文，被下一次执行直接继承了，导致结果越来越难解释。

我自己理解下来，这类问题和纯粹的调度问题也不是一回事，它更接近**数据库会话生命周期和批任务上下文管理**。
如果每次任务开始前都默认“环境一定是干净的”，现场很容易吃亏。

## 为什么重跑这么容易出上下文问题

我最近整理下来觉得，核心原因通常有三个：

1. 任务失败时，并不是所有中间状态都会自动消失；
2. 应用和调度系统常常会复用连接或复用执行环境；
3. 脚本设计时默认成功路径，没把重试路径当正式路径来设计。

所以真正到现场时，我自己更关注的不是“这次为什么失败”，而是：
**失败之后，下一次执行继承了什么。**

## 现场里常见的几类现象

1. 临时对象未清理，重跑时报对象已存在。
2. 会话级参数残留，第二次执行行为不同。
3. 上一次失败的阶段表还在，重跑结果掺入旧数据。
4. 长连接调度复用旧上下文，人工新开客户端却无法复现。
5. 同名中间表被不同批次复用，最后谁也说不清数据来自哪次运行。

## 我实际排查时一般先看什么

### 第一步：确认任务是短连接还是长连接

这一步我自己特别在意。
如果调度系统每次都新建连接，很多会话残留问题天然会少一些；
但如果系统会复用长连接，那就不能假设每次执行都是一张白纸。

### 第二步：检查是否存在“失败后仍保留”的中间对象

```sql
show tables;
```

我自己通常会特别关注：

- 阶段表；
- 临时辅助表；
- 按批次落地的中间结果；
- 上次重跑遗留的对象。

### 第三步：检查会话级设置和运行痕迹

如果某些行为和参数有关，就不能只看脚本内容，还要看它是不是继承了旧会话的环境。

## 一个更接近现场的例子

某批任务逻辑很简单：

1. 创建阶段表；
2. 校验阶段表；
3. 汇总写正式表。

但第一次执行在第二步失败，阶段表已经建出来。
第二次重试时，脚本里又直接 `create table stg_xxx as ...`，结果要么报已存在，要么人为改成 `insert into` 以后又把旧数据叠上去。

原始脚本示意：

```sql
create table stg_trade_chk_20260331 as
select
    store_id,
    sum(pay_amt) as amt_sum
from fact_order
where dt = '2026-03-31'
group by store_id;

select count(*) from stg_trade_chk_20260331;

insert into rpt_trade_day
select
    '2026-03-31',
    store_id,
    amt_sum
from stg_trade_chk_20260331;
```

如果不把重跑路径设计进去，这类任务只要失败一次，现场就会越来越乱。

## 我自己更倾向的处理方式

### 每次运行前先清理明确的中间对象

```sql
drop table if exists stg_trade_chk_20260331;
```

### 所有阶段表都带批次信息

这点我已经越来越倾向于当成硬规则。
没有批次信息的中间对象，出了问题很难追。

### 把“初始化环境”写进脚本开头

我自己更关注的是，把干净启动当成任务的一部分，而不是靠人工记得去做。

## 一个更稳一点的脚本示意

```bash
#!/bin/bash

DBHOST=192.0.2.159
DBPORT=5258
DBNAME=dw_retry
DBUSER=retry_user
BIZ_DT=2026-03-31
LOGDIR=/data/gbase/log/retry_ctx

mkdir -p "${LOGDIR}"

gccli -h ${DBHOST} -P ${DBPORT} -u ${DBUSER} ${DBNAME} &lt;&gt; "${LOGDIR}/retry_ctx_${BIZ_DT}.log" 2&gt;&amp;1
drop table if exists stg_trade_chk_${BIZ_DT//-/};

create table stg_trade_chk_${BIZ_DT//-/} as
select
    store_id,
    sum(pay_amt) as amt_sum
from fact_order
where dt = '${BIZ_DT}'
group by store_id;

select count(*) as stg_cnt
from stg_trade_chk_${BIZ_DT//-/};

delete from rpt_trade_day where rpt_dt = '${BIZ_DT}';

insert into rpt_trade_day
select
    '${BIZ_DT}',
    store_id,
    amt_sum
from stg_trade_chk_${BIZ_DT//-/};
SQL
```

我自己更看重这类脚本是不是把“初始化环境”和“可重跑”一起考虑进去了。

## 一些我实际见过的坑

| 常见坑 | 现场表现 | 我更建议的处理 |
|---|---|---|
| 默认环境干净 | 重跑结果不稳定 | 脚本显式初始化 |
| 中间表不带批次 | 数据来源混乱 | 统一命名规范 |
| 连接池复用旧会话 | 手工和调度不一致 | 按真实调用链排查 |
| 失败后直接再跑 | 旧状态继续污染 | 先清理再重跑 |

## 我最近更认同的一套处理顺序

1. 先确认连接是不是会复用。
2. 再确认失败后哪些对象会残留。
3. 然后把初始化动作写进脚本开头。
4. 最后再去讨论具体 SQL 本身。

我自己越来越觉得，重跑不是“补救动作”，它应该是设计时就要考虑进去的正式路径。
只要这个思路变了，很多现场问题其实会提前少一半。

## 结尾

我最近回头看 GBase 8a 里这类问题时，一个很明显的感受是：
任务第一次失败不可怕，可怕的是第二次重跑时，大家还默认它会在一张干净白纸上开始。

真正落到现场时，先把会话残留、中间对象和初始化动作收好口，再去谈重跑逻辑，通常更稳，也更容易复盘。

## 参考资料

```text
[1] GBase 社区个人中心
https://www.gbase.cn/community/user/46723

[2] GBase 8a 社区优质文章区
https://www.gbase.cn/community/section/11

[3] GBase 8a MPP Cluster SQL 参考手册
https://www.gbase.cn/community/post/1772

[4] GBase 8a 参数文章汇总
https://www.gbase.cn/community/post/2018
```





GBase 8a 会话残留和作业重跑时的上下文污染

GBase 8a 会话残留和作业重跑时的上下文污染

评论

热门帖子